AI Agent Controls

AI agent controls are the administrative and technical measures that keep an agent’s design, access, decisions, actions, and changes inside approved boundaries.

They turn a governance decision into something an organization can operate and test. A policy may say that an agent needs approval before issuing a refund above $500. The control is the approval service that blocks the refund tool until an authorized person approves the exact amount and account. The evidence is the approval record, tool decision, and resulting transaction.

That distinction matters because an instruction in a prompt can influence an agent without stopping it. High-impact controls need enforcement points outside the model, clear owners, useful evidence, and tested failure behavior.

TL;DR

A useful AI agent control system should:

1. Register each production agent, its owner, purpose, risk tier, and approved authority.
2. Turn each material risk into a clear control objective.
3. Put deterministic controls at identity, tool, data, approval, and execution boundaries.
4. Govern the context, Skills, Memory, and configuration that shape agent behavior.
5. Bind authority to the task, principal, parameters, time, and target system.
6. Limit retries, time, cost, tool depth, data volume, and external effects.
7. Check external outcomes instead of trusting the agent’s completion claim.
8. Record control decisions with stable identities and version references.
9. Test whether controls work across normal, edge, adversarial, and failure cases.
10. Review control health after changes, incidents, drift, and new use cases.

A control catalog is useful only when each control connects to a risk, operates at a real boundary, produces evidence, and has a response when it fails.

What Are AI Agent Controls?

AI agent controls reduce the chance or impact of an unwanted outcome. They can prevent an action, detect a problem, contain execution, require human judgment, recover state, or create evidence for later review.

A complete control has several parts:

• A risk or requirement it addresses
• A specific control objective
• A defined scope and trigger
• An owner accountable for operation
• An enforcement, review, or observation point
• Inputs and configuration the control depends on
• Evidence that shows what happened
• A test method and review frequency
• A response for failures and exceptions

“The agent should protect customer data” is not a control. It does not say what data is protected, what action is restricted, where the restriction is enforced, or how anyone can tell whether it worked.

“The customer-record tool denies export requests unless the agent identity has an export grant bound to the case ID, approved fields, destination, and one-hour window” is a control. A team can inspect its design, execute test cases, review denials and approvals, and investigate exceptions.

The NIST AI Risk Management Framework gives organizations a voluntary structure for incorporating trustworthiness into AI design, development, use, and evaluation. Agent controls are how many of those risk decisions become concrete operating measures inside a specific workflow.

Governance, Policies, Controls, and Guardrails

These terms overlap, but they do different work.

• AI agent governance sets decision rights, accountability, risk limits, review processes, and oversight.
• AI agent policy management turns organizational rules into current, owned, reviewable requirements for agents and operators.
• AI agent controls put those requirements into operation through enforcement, review, monitoring, testing, and response.
• AI agent guardrails are controls placed in or around a workflow to guide, block, detect, or stop behavior.
• AI agent testing executes cases to determine whether the agent and its controls behave as expected.
• AI agent assurance decides whether combined evidence supports a defined claim within stated limits.

For example, governance may decide that an agent cannot publish customer-facing legal terms without a human reviewer. The policy defines which changes fall into that class. Controls restrict the publishing tool, route the draft to an eligible reviewer, bind approval to the exact document version, reject stale approval, and log the final publication. Tests try normal publication, changed documents, expired approvals, alternate tools, and reviewer conflicts. Assurance considers whether that evidence supports the claim that unapproved terms cannot reach production.

Keeping these jobs separate makes weak spots easier to see. A policy without a control relies on voluntary behavior. A control without a policy may enforce the wrong boundary. A control without testing may never activate. A control without evidence cannot support audit or assurance.

Why Agents Need a Distinct Control System

Traditional application controls still matter, but agents add behavior that fixed workflows do not usually have.

An agent can choose among tools, form a plan over many steps, retrieve changing context, call another agent, adapt after failure, and act under a delegated identity. The same user request can produce different paths across runs. Tool output, external content, Memory, or a changed Skill can alter later decisions.

This creates several control problems:

• The action path may not be known when the workflow starts.
• A valid credential may still be used for the wrong purpose.
• One low-risk step can become high risk when combined with later steps.
• Retrieved content can influence a plan or tool call.
• An agent may report success even when the target system did not change.
• Retries can duplicate side effects or increase cost.
• A handoff can widen authority or lose the original approval terms.
• A context, tool, model, or policy change can alter behavior without an application-code change.

The control system therefore needs to follow the action across context delivery, planning, authorization, tool calls, external state, and evidence. It also needs to account for the versioned inputs that shaped the run.

Singapore’s Model AI Governance Framework for Agentic AI recommends technical controls across design, pre-deployment testing, gradual rollout, production monitoring, and change management. It also distinguishes structural and rule-based controls from model-based or prompt-layer controls, which is useful because the strongest enforcement point depends on the risk.

Start With the Risk-to-Control Chain

Do not begin by copying a large control list. Begin with the workflow and the outcomes the organization cannot accept.

For each material risk, write the chain in this order:

1. The use case and operating conditions
2. The asset, person, process, or obligation at risk
3. The unwanted event and its impact
4. The control objective
5. The control activity and enforcement point
6. The evidence the control produces
7. The test that challenges the control
8. The owner and failure response

Consider an agent that updates supplier bank details.

• Unwanted event: the agent changes payment details using a malicious email.
• Control objective: only verified requests from an approved supplier contact can change the record.
• Preventive controls: treat email content as untrusted data, require a case ID, verify the contact through a separate channel, restrict the tool to one supplier record, and require human approval for the exact old and new values.
• Detective controls: alert on unusual destination countries, multiple changes, approval delay, or a mismatch between case and supplier.
• Corrective controls: freeze payment, restore the prior record, revoke the session, preserve evidence, and open an incident.
• Evidence: input identifier, verification result, agent and principal identities, delivered context versions, tool request, policy decision, approval, record version, and external outcome.
• Tests: malicious instructions in email, lookalike domains, stale approval, changed parameters, duplicate retries, alternate tools, and dependency failure.

This chain gives every control a reason to exist. It also exposes gaps between a written rule and the point where an action can actually be stopped.

Put Controls Where the Model Cannot Override Them

Prompt instructions are useful for ordinary guidance, task framing, and behavior that cannot be expressed as a fixed rule. They are a weak sole barrier for sensitive data, money movement, account changes, code execution, publication, or deletion.

For high-impact actions, place enforcement in systems such as:

• Identity providers and token brokers
• Policy decision and enforcement services
• Tool gateways and MCP servers
• Approval services
• Sandboxes and network proxies
• Data stores and row or field access layers
• Target APIs and systems of record
• Deployment and change pipelines

The model can request an action. The control decides whether the request may proceed.

IMDA recommends deterministic, system-level safeguards for higher-risk actions where rules can be defined. Its framework gives a simple example: prevent a tool call at the tool layer or restrict it to read access instead of only telling the agent not to use the tool. The OWASP AI Agent Security Cheat Sheet similarly advises teams not to rely on model output for authorization decisions.

Model-based controls still have a role when a fixed rule cannot recognize the condition, such as classifying harmful or deceptive content. Treat their output as probabilistic. Measure error rates, define what happens when confidence is low, and add deterministic controls around high-impact downstream actions.

Build an AI Agent Control Catalog

A control catalog should cover the whole operating path. The sections below are a starting structure, not a universal checklist.

Inventory and ownership controls

Register every production agent and material agentic workflow. Record its purpose, owner, users, risk tier, lifecycle state, model and runtime, data classes, tools, integrations, other agents, and approved operating boundary.

Inventory controls should detect unregistered agents and stale records. Ownership controls should define who may approve changes, accept risk, respond to incidents, and retire the agent. A record with no active owner should not remain in production.

Context and configuration controls

Govern the instructions, policies, Skills, Memory, retrieval sources, tool descriptions, model settings, and runtime configuration that shape behavior.

Useful controls include:

• Review and publication for stable instructions and Skills
• Version history and audit for live Memory
• Independent permissions for discovery, reading, and changes
• Explicit Always routes for context delivery
• Authorized and audited route changes with tenant and data-class eligibility checks
• Source, integrity, freshness, and expiry checks
• Context size and conflict checks
• Point-in-time delivery records
• Separation between untrusted retrieved content and privileged instructions

These controls matter because the same code can behave differently under a changed context bundle. A release decision should identify the context versions it covers.

Identity and authorization controls

Give each agent a distinct, revocable identity. At action time, bind delegated authority to the intersection of the initiating principal, sending agent, receiving agent, task grant, target policy, and current approval. Keep the purpose, task, target, allowed action, data scope, parameters, time window, environment, tenant, and lifecycle state in that decision.

Use least privilege and deny by default. Reauthorize when the task changes, authority widens, approval expires, risk rises, or the workflow crosses a trust boundary. Do not let one agent pass broad credentials to another agent.

AI agent access control determines which resources an agent can reach. AI agent authorization makes the action-time decision about whether this agent may perform this action under these conditions. Both need records that can be tied to the resulting tool call.

Tool and integration controls

Maintain an approved tool registry with an owner, purpose, version, publisher, data profile, allowed operations, known side effects, and review date. Pin versions when a change can alter behavior or authority.

At the tool boundary:

• Require strict schemas and reject unknown fields.
• Allow only task-related operations.
• Validate object IDs, destinations, amounts, and other material parameters.
• Separate read, propose, approve, and execute capabilities.
• Set timeouts, rate limits, and idempotency keys.
• Restrict outbound hosts and protocols.
• Log allowed and denied calls without storing secrets.
• Verify the external result before reporting completion.

An approved tool is not automatically safe for every agent or task. The control decision should consider who is acting, why, on what object, with which parameters, and under which approval.

Data and Memory controls

Classify data before deciding which agents may use it. Apply purpose limits, minimization, tenant isolation, field restrictions, retention, deletion, encryption, and output controls at the data layer where possible.

Treat content from users, documents, websites, email, tools, and other agents as untrusted input. Preserve its source and trust label. Do not interpolate it into privileged instructions or executable commands.

AI agent Memory governance also needs write authority, provenance, scope, correction, expiry, and deletion controls. A false or malicious Memory entry can affect many later sessions, so Memory writes should not inherit trust merely because an agent produced them.

Action and approval controls

Classify actions by impact, reversibility, data sensitivity, external effect, and required judgment. Enforce approval for high-impact actions in a service the agent cannot bypass.

A valid approval should bind to:

• The exact agent and initiating principal
• The action and target record
• Material parameters and content version
• The approver and approval basis
• An expiry time and one-time or bounded use
• Any required separation of duties

If a parameter changes, require fresh approval. If the target system offers another path to the same effect, control that path too. AI agent human oversight is meaningful only when the reviewer has enough time, information, authority, and a working way to stop the action.

Execution and containment controls

Set limits for time, tokens, cost, retries, recursion, tool-call depth, concurrency, data volume, and external actions. Use idempotency and compensation for operations that can be repeated or partially fail.

Run untrusted code, browser tasks, and risky tools inside an AI agent sandbox with scoped filesystem, process, network, and credential access. Reset state between cases where persistence is not required. Define stop conditions that do not depend on the agent deciding to stop itself.

Containment should limit the result of a control failure. An authorization bug should not expose every customer record. A loop should not run without a cost ceiling. A compromised worker should not inherit the orchestrator’s full authority.

Output and outcome controls

Validate structured outputs against schemas and business rules before another system acts on them. Scan for sensitive data where the workflow can expose it, but do not treat output filtering as a substitute for access limits.

Check external state after an action. A successful HTTP response does not always mean the intended record changed, and an agent’s statement that work is complete is not independent evidence.

Outcome controls can reconcile the requested action, policy decision, approval, tool response, and system-of-record state. They should detect duplicate, partial, delayed, or contradictory results.

Monitoring, audit, and response controls

AI agent observability should collect the signals needed to detect control failures, drift, abuse, and degraded performance. Alerts need an owner, threshold, route, and expected response.

Retain stable references for the run, trace, context-delivery record, agent version, tool policy, authorization decision, approval, external action, and incident. Redact or minimize sensitive content before it reaches logs. Restrict access to evidence and apply retention rules.

Write material control decisions and action records to an append-only or tamper-evident store outside the agent’s write authority. Use trusted timestamps and integrity checks so investigators can detect missing, reordered, or changed records. Separate evidence-writing credentials from the credentials used to perform the business action.

A point-in-time agent audit should reconstruct what authority, context, tools, and controls applied when the agent acted. Logs that cannot connect these records make root-cause analysis and control testing slower.

Change and lifecycle controls

Define which changes require review, testing, reapproval, staged rollout, or rollback. Material changes can include the model, prompts, published Knowledge, Skills, Memory policy, retrieval source, tool schema, permission scope, approval rule, autonomy level, or connected agent.

AI agent change control should compare the proposed state with the approved state and identify which controls and tests the change affects. Monitor after rollout because a safe pre-production result does not cover every production condition.

Retirement controls should revoke identity and credentials, remove routes and integrations, preserve required evidence, handle retained data, transfer or archive owned resources, and verify that scheduled work has stopped.

Use Preventive, Detective, and Corrective Controls Together

One control rarely covers a material risk by itself.

Preventive controls try to stop the unwanted event. Examples include scoped credentials, tool denials, input schemas, approval gates, network restrictions, and change review.

Detective controls identify that an unwanted condition occurred or may be developing. Examples include anomaly alerts, drift checks, reconciliation, denied-call trends, unusual Memory writes, and missing delivery records.

Corrective controls contain impact and restore an accepted state. Examples include token revocation, circuit breakers, rollback, record restoration, agent suspension, context correction, and incident response.

For a high-risk workflow, ask three questions:

1. What stops the event?
2. What detects it if prevention fails?
3. What limits harm and restores state?

Also identify dependencies. An approval gate depends on identity, reviewer eligibility, parameter binding, clock integrity, and an enforcement point. If those dependencies fail, the approval control may look present while doing little.

For a high-impact action, an unavailable or indeterminate authorization, policy, approval, risk-classification, or required evidence service must stop execution or queue the request for authorized review without producing the external side effect. Do not turn a control outage into permission to proceed.

Write a Control Design Record

Give each material control a stable record that engineers, risk owners, operators, and auditors can understand.

Include:

• Control ID and name
• Linked risks, policies, and requirements
• Control objective
• Workflow and environment scope
• Trigger and decision logic
• Type: preventive, detective, corrective, or combined
• Mode: automated, manual, or hybrid
• Owner and operator
• Enforcement or review point
• Dependencies and trusted inputs
• Expected evidence and storage location
• Failure mode and fallback behavior
• Exception and compensating-control process
• Test cases and pass criteria
• Review frequency and change triggers

Use plain statements. “Review agent activity regularly” is hard to operate. “The workflow owner reviews all denied payment-tool calls and a risk-based sample of approved calls each week, records the result against the control ID, and opens an incident for any approval mismatch” defines who does what, when, and what follows.

Test Design and Operating Effectiveness

A control can be well designed and still fail in operation.

Design-effectiveness review asks whether the control, if implemented as described, can address the stated risk. Check its placement, scope, dependencies, bypass paths, evidence, and response.

Operating-effectiveness testing asks whether the control actually worked during a defined period or set of runs. Inspect executed cases and production evidence. Confirm that the right control version ran, the expected decision occurred, evidence was complete, exceptions were handled, and failures triggered the stated response.

Test controls with:

• Allowed actions that should pass
• Disallowed actions that should fail
• Boundary values and ambiguous inputs
• Expired, replayed, or parameter-mismatched approval
• Alternate tools and paths to the same outcome
• Prompt injection and untrusted retrieved content
• Identity, network, tool, and logging failures
• Duplicate retries and partial writes
• Multi-agent handoffs and authority narrowing
• Changed context, tool, model, and policy versions

The OWASP cheat sheet recommends structured security testing before production and after material changes, with retained evidence for the tested version, policies, abuse cases, observed control behavior, and accepted residual risk. Testing should include the control itself and the agent-specific paths that may bypass it.

Use AI agent testing to execute repeatable cases, and sample production operation where the risk and data rules allow it. A passing design review does not prove the control ran, while a sample of successful runs does not prove the control covers every path.

Define a Minimum Production Baseline

Not every agent needs the same control intensity. A read-only research agent and an agent that changes payroll records should not share one approval model.

Still, every production agent should meet a baseline:

1. Registered identity, purpose, owner, users, and lifecycle state
2. Documented risk tier and approved operating boundary
3. Current inventory of context, data, tools, integrations, and other agents
4. Least-privilege credentials and action-time authorization
5. Enforced approvals for high-impact or irreversible actions
6. Data, Memory, tenant, and destination restrictions
7. Time, cost, retry, recursion, and side-effect limits
8. Verified outcomes, audit records, monitoring, and alert ownership
9. Tested normal, adversarial, failure, stop, and recovery paths
10. Defined change, exception, incident, and retirement processes

ISACA’s August 2026 guidance on questions to ask before an AI agent goes live calls for a basic governance record covering ownership, purpose, lifecycle, delegation, tools, permitted and prohibited actions, logging, exceptions, and retirement. A shared baseline reduces the inconsistency that appears when each team invents its own production gate.

Add stricter controls when the agent can affect money, safety, regulated decisions, sensitive data, customer communications, production infrastructure, or other agents. Document accepted residual risk and the person authorized to accept it.

Common AI Agent Control Gaps

Control programs often look complete in a spreadsheet while leaving important paths open.

Watch for these gaps:

• The prompt contains the rule, but the tool still allows the action.
• The agent has a valid identity, but authority is not tied to purpose or parameters.
• Approval covers a draft, but the content changes before execution.
• The primary tool is restricted, but an alternate tool reaches the same system.
• Logs record the agent output but omit delivered context, policy decisions, or external outcomes.
• Memory can be changed without source, scope, or correction controls.
• A handoff gives the next agent broader authority than the first agent held.
• Monitoring creates alerts with no owner or response time.
• Tests cover average success but skip control bypass and dependency failure.
• A model or Skill changes without control impact analysis.
• An archived agent retains credentials, schedules, routes, or tool access.
• Evidence stores secrets or personal data that the control did not need.

Review gaps by tracing one real action end to end. Start with the initiating person and request, then follow context delivery, identity, policy decisions, tool calls, approvals, external state, evidence, and response. This often reveals breaks that a control-by-control review misses.

How Context Governance Supports AI Agent Controls

Many controls assume that the agent received the right policy, operating procedure, Skill, and working context. That assumption needs evidence.

Alignbase is an AI context control plane for governed agent inputs. Teams can manage Knowledge, Skills, and Memory as versioned Resources, control who may discover, read, or change them, independently route them as Always, and record what reached each agent.

That supports the control system in several ways:

• Stable policies and instructions can use review and publication.
• Skills can be versioned, approved, and routed to eligible agents.
• Memory can remain live and versioned with permissions and audit.
• Context routes can vary by agent or Group without changing repository access.
• Delivery records can identify published Knowledge and Skill versions and current Memory versions used in a run.
• Point-in-time evidence can connect agent behavior to the input bundle in force at that moment.

Alignbase does not replace runtime identity, authorization, approval services, sandboxes, data controls, tool enforcement, or monitoring. It governs a part those controls depend on: the context and Skill inputs the agent received. Connecting delivery evidence to runtime decisions makes the full control chain easier to test and audit.

Build the Control System in Risk Order

Start with one material workflow, not the whole agent estate.

1. Map the agent, users, context, data, tools, identities, handoffs, and external effects.
2. Name the unacceptable outcomes and rank them by impact and likelihood.
3. Trace existing controls to each risk and find unprotected paths.
4. Move high-impact enforcement out of prompts and into system boundaries.
5. Add stable IDs and evidence links across delivery, authorization, approval, tool use, and outcome.
6. Test normal, denial, bypass, failure, and recovery cases.
7. Define the production baseline, rollout conditions, alert owners, and stop authority.
8. Review evidence after rollout and update controls when conditions change.

Then repeat the pattern for the next risk tier. Reuse control designs where the objective and boundary are truly the same, but keep workflow-specific parameters, owners, evidence, and tests explicit.

The standard is simple: every material agent risk should map to a control that can operate, produce evidence, survive a realistic challenge, and trigger a defined response when it fails.