What should security teams do when agents can change tool configuration?

Why mutable agent tool configuration changes the security model

When an agent can edit its own tool configuration, the real trust boundary is no longer the approval prompt or the local client. The security question becomes whether the environment still enforces policy when the agent, user, or endpoint is untrusted. Treat configuration as an attack surface, not a convenience feature, because a changed server list, endpoint, or tool manifest can redirect execution to a rogue destination.

That shift matters because a local approval model only protects the normal path. If the agent can rewrite what it is allowed to call, an attacker does not need to defeat the prompt every time, they only need to alter the configuration once. The control objective is durable enforcement, meaning the policy must live outside the mutable client state and remain effective even after local tampering.

That is why guidance for tool and plugin security focuses on scoped tool permissions, validation, and explicit allowlists rather than trusting whatever the client declares at runtime. It is also why a MCP security guide is relevant here: the client configuration, server selection, and token handling all need guardrails that survive local compromise.

What fails when policy stays inside the mutable client

A mutable configuration turns policy into a target. If write access is broad, an agent or attacker can swap approved servers for unapproved ones, change endpoint metadata, or introduce a new tool path that still appears legitimate to the local process. The failure is not just unauthorized access, it is control-plane drift, where the system behaves differently from what the security team thinks it enforces.

Logging is essential because configuration changes are security events, not routine housekeeping. Without a reliable audit trail, teams cannot distinguish an expected admin change from tampering, and they lose the ability to reconstruct which tool target was active when an action occurred. That makes detection, incident review, and containment much harder.

Unapproved servers are especially dangerous because they can become a hidden execution path even when the agent still appears to be operating normally. If the local file can be altered, the control must still block the connection or invocation at enforcement time. In practice, that means server admission, tool authorization, and policy evaluation need a source of truth that the endpoint cannot rewrite.

How to design controls that survive endpoint tampering

Move the policy decision out of the agent workspace and into a control point the endpoint cannot easily alter. That usually means enforcing server allowlists, write restrictions, and approval logic on a managed policy service, gateway, or central control layer rather than in a local config file alone. The client may request, but it should not be able to redefine what is trusted.

For security teams, the strongest model is to separate three things: who may change configuration, which servers are permitted, and which actions the agent may perform. Those should not be bundled into one editable file. If the client can both describe the tool and approve the tool, the control is too weak for a hostile endpoint.

When the question is whether to trust a local file, the answer should be no unless the file is treated as advisory only. A resilient design validates configuration against a protected policy source at startup and at change time, then fails closed when the declared server or tool is not on the approved list. That gives you a control that still works after local compromise instead of only before it.

This is also the point where AI agent authorisation becomes practical, because per-action policy and least privilege are what stop a mutable client from turning broad intent into broad authority. For teams standardising governance, the agentic AI security policy template is useful as a structure for registration, oversight, monitoring, and retirement controls around that change process.

Practitioner Guidance

What to verify: Confirm that configuration changes are authenticated, centrally logged, and independently enforced before the agent can use the new settings. The key test is simple: if a local config file is edited on the endpoint, does the platform still block an unapproved server or tool?

Decision rule: If the agent can materially change its own tool targets, treat that configuration as hostile input and require an external policy check before execution. If you cannot prove the control survives endpoint tampering, do not rely on the client as an enforcement point.

What good looks like: Approved servers remain usable after normal updates, but any deviation from the approved set is rejected, logged, and visible to operations. The security team should be able to show that policy still holds when the workstation, container, or local runtime is modified.

Practitioner takeaway: The objective is not to make configuration immutable everywhere, but to make authorization non-bypassable where it matters, so a changed client cannot redefine the trust boundary.

Related resources from NHI Mgmt Group

• How should security teams manage permissions for AI agents?
• How should security teams govern AI agents that use OAuth access?
• How should security teams limit the risk from AI agents that have access to production systems?
• How should security teams govern AI agents that can access enterprise systems?