AI agent governance cannot stop at identifying risk. A risk score can tell an organization that an agent deserves more scrutiny. A review board can decide that an agent should have limited autonomy. A policy can say that sensitive actions require human approval. None of those things, by themselves, stop an action.
The operational question is harder: how do we translate an approved risk decision into controls that actually constrain what an agent can do?
That question matters more as AI systems move from informational to operational. An agent that summarizes a document presents a different risk profile from an agent that can call APIs, modify records, move files, send messages, provision access, execute code, or trigger downstream workflows. Once an agent can produce a consequence in another system, governance has to move beyond policy language. It needs an execution model.
The model may be nondeterministic. The authority should not be.
We may not be able to predict every response an AI model generates. We can still define which systems an agent can reach, which tools it can invoke, what data it can access, what actions it can execute, what limits apply, and what must happen before a high-consequence action is allowed. That is where operational agent governance begins.
ARGM Should Not Terminate at a Risk Score
Earlier in this series, I introduced the Agent Risk Governance Model (ARGM) as a way to evaluate agent risk before granting meaningful enterprise authority. The assessment asks seven questions:
| Dimension | Question |
|---|
| Data Access | What can the agent read? |
| Authority Level | Can it recommend, or can it write, modify and execute? |
| System Reach | What systems, APIs and tools can it reach? |
| Blast Radius | What is the impact if it fails, is manipulated or is misused? |
| Autonomy Tier | Does it act independently, or with a human in the loop? |
| Visibility | Can we reconstruct the trigger, tool calls, target systems and resulting actions? |
| Accountability | Who owns and accepts the risk? |
Those questions help classify risk. But classification is not enforcement. The next step is to convert those answers into an explicit statement of approved authority. I call that an Agent Control Contract.
A practitioner construct, not an external standard
The contract defines what a specific version of an agent is permitted to do and provides the requirements that identity systems, runtimes, tools, gateways, target applications, and monitoring platforms must implement.
This is the same construct the Agentic Identity Lifecycle Practitioner Guide introduces at Stage 4 (Define Contract / Baseline Authority) and approves at Stage 5 (Authorize Contract v1). That guide establishes what the contract is and where it sits in an agent's lifecycle. This article extends it operationally: how the contract gets assembled across real infrastructure, where it's actually enforced, and what has to happen when it changes.
Risk Assessment → Agent Control Contract → Enforce + Observe
What is the risk? → What have we authorized? → Where do we make that authorization real?
The Agent Control Contract
Consider a simple HR agent whose purpose is to triage a shared mailbox and prepare draft responses. Its first approved contract might look conceptually like this:
HR-AGENT CONTRACT v1
purpose: triage HR mailbox, draft replies
runs_on: managed cloud
principal: agent:hr-assistant
allow:
- outlook.read
- outlook.create_draft
deny:
- outlook.send
- external_egress
- sharepoint.*
limit:
- 5 messages / run
approval:
- external send
- bulk change
telemetry:
- agent trace
- policy decision log
- Exchange audit
contain:
- disable agent identity
- deny at tool broker
owner:
- HR Operations
- IAM Platform
version: v1
The important part is not whether every organization literally stores this information in YAML. The important part is that the decisions are explicit. What is the agent's purpose? Where does it execute? What identity or delegated authority does it use? Which tools are available? Which actions are allowed? Which actions are denied? What limits apply? What requires approval? What evidence should exist after execution? How is the agent contained? Who owns it? And which approved version of that authority is currently deployed?
That creates something behavioral analytics cannot create on their own: a declared boundary of authorized capability.
Baseline authority before you baseline behavior.
Same Risk Model. Different Control Plane.
The same risk questions can be applied across agent environments. The implementation cannot. Where an agent runs changes what an organization can identify, observe, enforce, and revoke. The Practitioner Guide makes this distinction briefly, as a reason Discover treats endpoint/local, SaaS, and cloud as separate evidence planes. Here it's the operational detail behind that shorthand — what each environment actually gives you at each control point:
| Environment | Identity | Enforcement Point | Telemetry / Trace | Containment |
|---|
| Managed Cloud | Dedicated workload/agent identity or delegated authority | IAM, RBAC, harness, tool broker, API gateway | Runtime trace plus cloud/resource audit | Disable identity, remove role, revoke credential, deny subject |
| SaaS-Hosted | Platform identity, integration, user delegation, or app grant | SaaS policy, approved integrations, downstream permissions | Provider audit where supported | End session, disable integration, revoke grant |
| Local IDE / CLI | May use the human user's credentials plus local session context | Managed settings, harness hooks, sandbox, broker, endpoint controls | Harness/runtime telemetry plus endpoint and target-system audit | Kill process/session, revoke tool access, disable broker or MCP path |
This distinction matters because phrases such as "monitor the agent" or "revoke the agent" sound straightforward until we ask where those actions actually occur. In a managed environment, the agent may have a dedicated workload identity. In a SaaS platform, the provider may expose some combination of user, integration, application, and agent-session context. In a local coding environment, the agent may execute inside the human user's session and may use the human user's credential. The downstream target might simply see principal = user:jdoe — it may have no native understanding that an AI agent caused the action.
The governance requirement remains consistent. The control point changes.
Six Control Planes for Operational Agent Governance
There is no universal agent-security control plane. Operational governance has to be assembled across the surfaces an agent actually crosses.
1. Identity
Whose authority is available to the agent — OAuth scopes, application permissions, workload roles, resource entitlements, credential lifetime, or delegated access.
2. Runtime / Harness
The scaffolding around the model that turns reasoning into execution — session, tools, MCP connections, hooks, approvals, sandboxing, and runtime traces.
3. Tool / MCP
Which tools, functions, plugins, or MCP capabilities are available to the agent, and which are omitted entirely.
4. Policy / Enforcement
A controllable decision point between agent intent and downstream consequence — broker, gateway, policy engine, or target application.
5. Target System
The system authoritative for the final effect — the record of what actually happened, whether or not it understands agent context.
6. Telemetry / Correlation
Correlating the evidence the other five planes produce — intent, decision, and effect — into a reconstructable transaction.
1. Identity Plane
The identity plane answers: whose authority is available to the agent? Where supported, operational agents should use attributable workload, application, or agent identities rather than simply inheriting broad human authority. Where human delegation is necessary, that delegation should be explicit and bounded. The identity layer establishes the maximum authority available to the agent.
Identity is necessary. It is not sufficient. An identity provider may know which principal authenticated without knowing which agent session selected the downstream action.
Authentication tells us whose authority was presented. It does not always tell us what acted.
2. Runtime / Harness Plane
The model is not the entire agent. The agent runtime or harness is the scaffolding around the model that turns reasoning into execution. Depending on the architecture, the harness may manage the agent loop, session state, tools, MCP connections, context, hooks, approvals, sandboxing, and runtime traces. This makes the harness an important source of agent context. It may expose information such as:
agent_session
agent_version
initiating_user
requested_tool
tool_arguments
trace_id
That context becomes particularly valuable when the downstream target sees only the human principal. The harness may also provide an enforcement opportunity — a pre-tool control, for example, may inspect a proposed action before the tool executes. But a hook is not automatically a security boundary. If it can be bypassed, or if its failure mode allows execution to continue, then the hook may provide useful telemetry without providing reliable enforcement.
The right question is not simply does the runtime support hooks? It is:
Can this control reliably prevent the consequence we are trying to prevent?
3. Tool / MCP Plane
An agent should not automatically receive every capability the human operator could theoretically access. Tool authority is privilege. An HR agent that only needs to read email and create drafts does not need send_email, delete_file, run_shell, create_user, or unrestricted SharePoint access simply because those tools exist.
Least privilege therefore applies at more than the IAM layer. It also applies to which tools and capabilities the agent runtime can invoke. The Agent Control Contract should define which tools, functions, plugins, or MCP capabilities are available and which are omitted entirely. Removing an unnecessary capability can be stronger than exposing the capability and attempting to detect misuse later.
4. Policy / Enforcement Plane
At some point between agent intent and downstream consequence, the organization needs a controllable decision point. That may exist in a tool broker, authorization service, agent harness, API gateway, service layer, policy engine, native platform control, or target application. The specific product is secondary. The operational requirement is:
Can the organization evaluate a proposed action before it creates the consequence?
Suppose the HR agent attempts:
agent: hr-assistant
tool: outlook.send
recipient: external@example.com
contract: hr-agent-v1
Version 1 does not authorize mail sending. The expected result is straightforward: DENY. No behavioral anomaly model is required to determine that. The request is outside the declared authority.
A different request may be allowed in principle but still carry enough consequence to require intervention. For example:
tool: sharepoint.move_file
count: 200
data_classification: confidential
The decision could become REQUIRE_APPROVAL. The objective is not to put a human into every agent loop. The objective is to reserve human intervention for actions whose potential consequence justifies it.
5. Target-System Plane
The target system is authoritative for the final effect. Exchange knows whether a message was sent. SharePoint knows whether a file moved. A database knows whether a record changed. A cloud platform knows whether a resource was created or deleted.
But the target system may not understand the full agent context that produced the action. It may record:
principal = user:jdoe
result = moved
That proves which credential or principal reached the target. It does not necessarily prove whether John manually initiated the operation, whether an agent selected the tool, which agent version executed, or which approved authority contract applied. This is why downstream audit alone cannot solve agent accountability.
6. Telemetry / Correlation Plane
The monitoring layer should not be expected to manufacture evidence the upstream systems never produced. Its job is to correlate the available evidence. For an operational agent, three questions matter:
IntentWhat did the agent try to do? — Agent runtime / harness
DecisionWhy was the action allowed, denied, or escalated? — Policy, approval, or broker layer
EffectWhat actually happened? — Target-system audit
A correlated transaction may look something like this:
user:jdoe
↓
agent_session:sess-7281
↓
tool:sharepoint.move_file
↓
contract:hr-agent-v2
↓
decision:allow
↓
downstream_event:evt-19a
↓
result:moved
This is the operational model investigators should be able to reconstruct.
No single log is the truth. Correlation reconstructs the action.
The SIEM is valuable here. But the SIEM is not creating the original evidence. It is connecting evidence generated across the identity, runtime, enforcement, and downstream control planes.
Attribution Is Not Authentication
Agent identity conversations often collapse several different questions into one. They should be separated. This is the "one action, three identities" distinction from the Practitioner Guide, applied to a contract-enforcement decision instead of a lifecycle stage. For one action, ask:
What acted?hr-agent / session:7281
Whose authority reached the target?agent:hr-assistant or user:jdoe
In a managed-cloud architecture, all three may be distinguishable. In a local environment, they may partially collapse. The agent may execute inside the user's session, and the downstream request may use the user's credential even though the runtime still knows that a specific agent session selected the action.
Authentication context is not always agent attribution.
For operational agents, ask two separate questions: what principal signed the downstream action, and what evidence proves an agent caused it? If an organization cannot answer both, its accountability model is incomplete.
The Harder Problem: Legitimate Agent Change
Agent behavior will change. Sometimes that will indicate misuse. Sometimes it will simply mean the development team shipped a new feature. Those are not the same event.
Return to the HR agent. Version 1 is authorized for:
systems:
- outlook
actions:
- mail.read
- mail.draft
limit:
- 5 messages / run
Later, the business legitimately wants the agent to organize documents inside a specific HR SharePoint site. Version 2 becomes:
systems:
- outlook
- sharepoint:HR-Operations
actions:
- mail.read
- mail.draft
- sharepoint.read
- sharepoint.move_file
limit:
- 20 file moves / session
From a purely behavioral perspective, the agent now looks different. It touches a new system. It invokes different tools. Its action volume changed. But that does not automatically mean the agent has drifted maliciously. Its authorized capability changed because the product legitimately changed.
The governance response should therefore not be "teach the detector that this is normal now." The response should be:
Reassess → Version → Authorize → Deploy
The control contract changes first. Then the implementation changes to match it:
Identity grants — updated if new authority is required
Harness configuration — new approved tools or integrations
Policy — new permitted systems, actions, limits, or approval rules
Telemetry — updated evidence requirements
Containment — confirmed shutdown handles for the expanded capability
This creates a much cleaner division between three different security signals:
Hard BoundaryUnauthorized tool, target, data, or privilege → Deny
Consequence BoundaryDestructive, financial, privileged, or sensitive action → Step-up / Human Approval
Behavior SignalNovel timing, sequence, frequency, or volume → Score, Prioritize, Investigate
This matters operationally. A dynamic AI agent should not require a SOC analyst to redefine "normal" every time the development team introduces a legitimate capability.
Behavior tells us something changed. The control contract tells us whether that change was authorized.
Behavioral analytics remain useful. They become evidence rather than the primary authorization mechanism.
A Worked Example Across the Six Control Planes
Now put the pieces together. The HR operations team deploys an agent to triage a shared mailbox, draft routine responses, and eventually organize approved HR documents. Under Version 1, SharePoint is not authorized.
Identity — the agent receives only the authority necessary to read the mailbox and create drafts.
Runtime / harness — the agent session, version, initiating context, requested tool, and trace information are recorded.
Tool — the runtime exposes mailbox read and draft capabilities but does not expose SharePoint write operations.
Policy — consequential tool calls are evaluated against hr-agent-v1.
Target system — Exchange records the resulting mailbox action.
Telemetry — the organization correlates intent, policy decision, and downstream effect.
Now suppose the agent processes poisoned content that attempts to manipulate it into sending confidential information externally. The runtime may produce:
agent_session: sess-7281
tool: outlook.send
recipient: external@example.com
attachment: confidential-file
The contract says:
outlook.send = denied
external_egress = denied
The request is stopped at a controllable point before the target system processes it. The attempt is still logged. Security can investigate it. But the organization's protection does not depend entirely on a SOC analyst noticing that the activity "looks weird." The authority boundary already answered the question.
That is the difference between monitoring risk and controlling it.
What Happens Without a Dedicated Agent-Security Platform?
This model should not depend on purchasing a new product. Specialized non-human identity and agent-security platforms can automate discovery, privilege analysis, lifecycle governance, behavioral analysis, and policy orchestration. They can reduce operational friction. They are not the underlying architecture.
Most enterprises already own portions of the required control system through identity management, endpoint security, cloud and SaaS audit, runtime telemetry, gateways, target-system logs, and SIEM. The first implementation question should therefore not be "which AI security product do we buy?" It should be:
Which control planes does this agent cross, and what can each one actually see or stop?
That question remains valid whether the organization has a dedicated NHI platform or is assembling the control model from systems it already owns.
Six Identity Disciplines Still Apply to Agents
Agent governance does not replace identity governance. It extends it. The Agent Control Contract gives traditional identity disciplines something more concrete to govern.
1. Joiner, Mover, Leaver for Agents
Agents need lifecycle events just as human and non-human identities do. A joiner event should establish more than the existence of an identity — it should establish the agent's purpose, owner, runtime, principal, approved systems, tools, risk tier, telemetry requirements, and containment mechanism.
A mover event occurs when something material changes: a new tool, a new target system, expanded data access, a different owner, a different runtime, greater autonomy, or increased privilege. A mover event should trigger reassessment and, where appropriate, a new control-contract version.
A leaver event should remove more than the credential. It should account for identities, tokens, integrations, scheduled jobs, tool access, delegated trust, background workers, and any residual execution path. An agent whose human owner leaves should not quietly become an orphaned production identity.
2. Access Certification
Traditional access reviews often ask whether a human still needs a role or entitlement. Agent certification should ask whether the agent still needs its declared capability envelope. A reviewer should be able to understand what the agent is for, who owns it, where it runs, what identity it uses, which systems it reaches, what tools it can invoke, which consequential actions are possible, and which control-contract version is currently approved.
That creates a better review experience than asking a business owner to interpret a list of opaque OAuth scopes with no operational context. The certification question becomes:
Does this agent still require this authority to perform its approved purpose?
3. Privileged Access Management for Agents
Privileged authority should not become permanent simply because the principal is non-human. Where feasible, agents should receive task-scoped, short-lived, or just-in-time privileged access rather than persistent administrative privilege. An agent that occasionally needs an elevated capability should not necessarily remain privileged between tasks.
For sensitive actions, an organization may also choose to broker access rather than expose the underlying privileged credential directly to the agent runtime. The Agent Control Contract should identify which actions cross the privileged boundary and what control must exist before that authority is exercised.
4. Separation of Duties
An autonomous system should not automatically be allowed to propose, approve, and execute the same high-risk transaction. Traditional separation-of-duties concepts still apply — and in some cases they become more important, because agentic workflows can collapse several business functions into a single automated path.
An agent that generates a payment should not necessarily approve that same payment. An agent that recommends an access change should not necessarily authorize and execute it. An agent that detects a policy exception should not necessarily be the only authority deciding that the exception is acceptable. The independent control may be another human, a policy engine, a separately governed service, or another agent operating under a distinct authority boundary. The key requirement is that independence remains real rather than merely logical.
5. Agent-to-Agent Trust Chains
Multi-agent systems introduce a delegation problem. Suppose Agent A calls Agent B, which calls Tool C, which reaches System D. The organization should be able to determine how authority moved across that chain: what did Agent A authorize? What identity did Agent B use? Did Agent B inherit Agent A's full permissions, or was a narrower authority delegated? Which control contract governed the downstream call? Can the chain be reconstructed after the fact?
Trust should not silently expand because another agent entered the workflow. A sound delegation model should preserve or reduce the approved authority envelope, not accidentally widen it.
6. Continuous Authorization
Continuous authorization does not mean asking a human to approve every agent action — that would create approval fatigue and eventually convert governance into a rubber stamp. It means authorization remains sensitive to current execution context: the agent identity, contract version, requested tool, target resource, data classification, transaction size, environment, session context, delegation chain, and potential consequence.
Low-risk activity inside the declared contract can proceed automatically. Hard authority violations should fail. High-consequence actions may require step-up approval. Behavioral anomalies may increase risk or trigger investigation. That keeps humans focused on consequential decisions rather than turning every normal agent action into a ticket.
Three Technical Details That Matter
1. Does hashing tool arguments (args_sha256) break incident response?
It creates a deliberate trade-off. Centralizing raw prompts, secrets, and full tool payloads can turn the logging platform into another sensitive-data repository. Structured metadata plus a canonicalized payload hash can help investigators determine whether a known candidate payload matches the executed request without placing the cleartext payload in routine telemetry.
But a hash is not replay. If the original payload was not retained, the hash cannot reconstruct it. If exact forensic reconstruction is required for a particular risk tier, the original payload would need to be preserved separately using appropriately restricted, encrypted evidence storage and retention controls.
A hash can help verify equivalence to a known payload. It cannot recreate a payload that was never retained.
2. Is indirect prompt injection just another input-validation problem?
Not entirely. Traditional applications often provide stronger separation between application control logic and submitted data. LLM systems may process system instructions, user instructions, retrieved information, documents, web content, and other untrusted material within the same reasoning context. That makes input sanitization alone an incomplete security boundary.
Prompt filtering, validation, content isolation, and prompt-injection detection can still provide meaningful defense in depth. But for an action-taking agent, a stronger security boundary is execution authorization at a controllable point before consequence — depending on the architecture, that control might exist in the harness, tool layer, broker, gateway, identity layer, or target system.
Treat prompt-injection detection as defense in depth. Treat execution authorization as the control that constrains consequence.
3. What does OAuth token revocation really mean in containment?
Token revocation and execution containment are related, but they are not identical. Revoking a refresh token or grant can prevent additional credential issuance. Containment of access tokens that have already been issued depends on the credential model and the systems enforcing access — for self-contained signed tokens, a resource server may validate the token locally and continue accepting it until expiration unless the architecture supports an additional revocation or deny-state mechanism.
One enterprise pattern is therefore to combine credential revocation with another enforcement handle capable of rejecting a subject, session, token identifier, integration, or tool path. The exact mechanism depends on the architecture.
A kill switch needs a control handle.
If an agent uses a human user's unrestricted credential and there is no agent-specific enforcement point, there may be no clean "disable only the agent" operation. That is an architectural limitation, not a SIEM problem.
What Exactly Are You Killing?
Containment should be designed before the incident. Different environments expose different control handles. Cloud may provide an agent identity, workload credential, role, token, or gateway subject. SaaS may provide a session, integration, app grant, or workspace permission. Local environments may provide a process, session, tool permission, harness control, broker path, or MCP connection.
The test is simple: if this agent begins doing something dangerous tonight, what exact control prevents the next action?
If the organization cannot identify that control, the containment design is incomplete.
The Operating Model
Operational agent governance reduces to seven questions.
| Step | Question |
|---|
| See It | Where does it run? |
| Identify It | Who asked, what acted, and whose authority reached the target? |
| Contract It | What is it explicitly allowed to do? |
| Enforce It | Where can an action be stopped before consequence? |
| Trace It | Can intent, decision, and effect be correlated? |
| Version It | Did legitimate capability change? |
| Contain It | What control handle shuts it down? |
This is not a replacement security stack. It is a way to apply identity, authorization, runtime control, observability, and incident response to systems whose decision-making is becoming increasingly autonomous.
The agent may select the tool. The agent may determine the next action. The agent may execute. But the organization still chooses the authority it grants. And the organization still owns the consequence.
An AI agent may execute the action. A human organization still owns the risk.
That is why agent governance cannot end at policy. It has to reach the execution path.
You cannot govern what you cannot see. You cannot control what you cannot intercept.
Practitioner Takeaway
Do not begin by trying to solve every AI-agent problem across the enterprise. Start with one operational agent. Ask the seven risk questions. Create its Agent Control Contract. Identify the control planes it actually crosses. Determine what each plane can observe, enforce, and revoke. Then test the uncomfortable scenarios:
- What happens if the agent requests a tool it was never authorized to use?
- What happens when a legitimate release expands its capabilities?
- What evidence proves an agent, rather than the human user, caused an action?
- What happens if the runtime or harness control fails?
- If the agent must be stopped immediately, what exact control handle do you pull?
When those questions have concrete engineering answers, agent governance has moved beyond documentation. It has become operational.
This is written for the security, identity, and platform leaders who own that decision once an agent program moves past pilot — the people who will be asked, after an incident or before a board review, what exactly stopped it.
Start with one operational agent
This model doesn't require a platform purchase or an enterprise-wide rollout. It requires one agent, an ARGM™ assessment, and a first control contract. That's a scoped, bounded engagement — not a program.
Book a call to scope your first agent contract →