AI agents: govern what they can do

An agent is not assessed only by the model it uses. Its tools, the information it receives and the effects it can produce also matter.

The use case needs understandable boundaries

When I assess an AI solution, I need to understand what the business wants to do and which capability we are authorizing. Summarizing documents, querying a system and changing records have different impacts. Using the same model does not make them a single decision.

I would document users, information, tools and permitted effects, together with who validates results and what happens when the system is unavailable. Scope should be explainable without a commercial description. If an agent can execute actions, I need to know which ones, on which resources and under which identity. A generic authorization to “use AI” leaves too many questions open to design permissions, responsibilities and tests that work in everyday operations.

Define the scope

Record the use case, users, data sources and permitted actions. A change in tools, integrations or user population may require a new assessment.

MCP connects capabilities; review what it exposes

An MCP server can provide tools and information access. To review it, I need to understand each exposed capability, its parameters, credentials and authorization. Trust in the supplier does not replace that review, and an internal server can also have excessive permissions.

I would separate queries from changes and check where access is enforced. A tool description saying “read-only” does not technically prevent a write if the service accepts it. The control must exist in the component executing or authorizing the action. I would also review accessible destinations and how consent or delegation works. We must be able to remove the integration without relying solely on the agent deciding to stop using it. Authorization needs to remain effective outside the model’s reasoning.

From request to authorized action

UserRequests an activity within the approved use case.
AgentProposes an action and its parameters.
Authorization and boundariesValidate scope; human approval where required.
MCP tool and serviceCheck permissions and execute the authorized operation.
Resource and effectRecord the outcome and link it to the request.

Retrieved content does not grant permissions. Boundaries are enforced by the components authorizing and executing actions.

An illustrative diagram of the article’s approach; not an official framework or supplier model.

Design execution boundaries

Separate reading and writing. Constrain high-impact actions and define when human intervention is required. Treat instructions in external content as untrusted data.

Retrieved information can try to issue instructions

A document, web page or tool response may contain instructions attempting to change the agent’s behavior. The problem arises when that content is treated as authority to retrieve more data, modify a resource or send information elsewhere.

I would test scenarios representing those deviations. For example, a document asking the agent to include additional information in a message, or a response suggesting another tool outside scope. We need to check which action was attempted and which barrier prevented it. Model instructions can help, but sensitive decisions require permission and execution controls. Test evidence should include actions and parameters, not merely a cautious-sounding textual answer. We also need to record the paths that were not tested instead of presenting limited results as complete assurance.

Example: from summarizing documents to sending messages

An agent approved to summarize documents later gains a tool to send messages to third parties. Even if the model stays the same, it can now create an external effect. Review permitted recipients, information it may include and actions requiring approval. Approving a purpose does not authorize every expansion of capability.

Human approval needs specific information

For a high-impact action, a generic confirmation may add very little. The approver should understand what will happen, with which data and to which destination. In the messaging example, this includes recipient and content before execution.

We also need to ensure the approved operation matches the executed one. If parameters change after review, authorization may no longer represent the action. I would define which changes require renewed confirmation and the limits of automation. I would not add manual approval to every step without understanding the activity: that can encourage automatic acceptance through fatigue. The level of intervention should reflect impact and let the reviewer make an informed decision, with enough context to reject or modify the proposed action.

A test that produces evidence

Scenarios with content attempting to alter the agent’s instructions help assess its boundaries. The relevant result is not just the textual response: it also matters whether it invoked a tool, which parameters it used and whether it accessed information outside its scope. Logs should not become an unnecessary copy of sensitive data.

Keep an inventory of capabilities

An AI application inventory is incomplete if it records only the supplier or model name. We need to know which integrations are active, what data they reach and which actions they enable. Two uses of the same service may require different controls.

I would link each case to its owner, approved configuration and completed tests. I would also distinguish available capabilities from enabled ones. A tool offering message delivery does not mean that permission is authorized; we need to check the configuration preventing its use.

Changes should be reported before expanding the agent’s effects. Adding an MCP server, repository or user population may alter exposure. Assessment should focus on the change while preserving the connection to the original purpose.

For periodic review, I would select representative executions and check whether they match the approved case. I would also look at unused permissions and tools added during testing. A proof of concept needs an environment, boundaries and completion criteria. If it continues operating and gains users without a new decision, actual scope diverges from the inventory. Correcting that gap requires reviewing capabilities and access, not merely updating an initiative’s name in a list. The inventory should help us identify who decides on that change and which evidence is needed before it proceeds.

Ensure traceability

Link execution, agent identity, initiating user and resulting action. Define mechanisms to stop the agent and revoke its access.

Operate, stop and reassess the scope

An agent needs owners for configuration, access and incidents. We must be able to stop execution, revoke credentials and identify completed actions. We should also define retry behavior: a second call can repeat an external effect if the service does not prevent duplicates.

Before expanding usage, I would review allowed and prohibited scenarios, tool failures and permission changes. Logs should connect the request, identity and action without unnecessarily storing sensitive information. To assess results, I would look at scope deviations, effective blocks and test coverage as well as usage. A new tool or integration serving more users can change the risk even when the model remains unchanged. That expansion deserves a specific assessment and a new decision on its boundaries.