AI Security Notes · 03
Inside an Agent Security Control Plane: From Delegated Authority to Execution
How to preserve business intent as AI agents move from investigating a problem to changing enterprise systems.
In What Agentic Security Actually Means, I introduced four security boundaries: identity, authority, execution, and evidence.
In AI Agents Are the New Digital Identities, I explored why valid credentials and permissions do not guarantee an appropriate action. An agent can operate within its technical permissions while exceeding its intended business mandate.
The next question is architectural: how do we preserve that mandate as an agent moves from receiving an assignment to executing an API call?
An agent security control plane connects the services that establish authority, evaluate proposed actions, enforce decisions, and preserve evidence. Its value becomes clearer when we follow one investigation through those boundaries.
The investigation: one account, one assignment
A SOC analyst receives an alert about suspicious sign-ins to an employee’s account. The incident platform creates INC-4821, associating the authentication events with user-1042.
The analyst assigns an AI agent to investigate. Enterprise policy permits automated containment of standard accounts when defined evidence requirements are met. Disabling privileged or business-critical accounts requires independent approval.
After reviewing the evidence, the agent proposes disabling user-1042.
The account belongs to a senior executive. The unusual sign-ins could indicate compromise—or legitimate travel.
Before allowing the operation, the system must establish whether the assignment covers this account, whether containment conditions are satisfied, and whether approval is required.
How the controls fit together
The main path runs from the agent through a gateway, policy engine, and trusted executor. Supporting services supply the task grant, verified records, and any required approval.
1. Give the agent a bounded assignment
The analyst’s instruction describes an objective. A trusted authorization service establishes the authority to pursue it.
After verifying the analyst’s right to delegate the task, the service creates a short-lived grant:
| Boundary | Authority granted |
|---|---|
| Actor | The investigating agent |
| Business context | INC-4821 |
| Eligible target | user-1042 in tenant-a |
| Operations | Read evidence and request account disablement |
| Condition | Protected accounts require approval |
| Lifetime | A defined investigation window |
The eligible target comes from validated incident records. The agent cannot extend its authority by placing another account identifier in a request. A broader investigation requires an authorized scope update.
Delegation must narrow—not expand—authority
Suppose the investigating agent asks a specialist agent to analyze the sign-in history. That specialist needs evidence access, not permission to disable accounts.
Its grant should contain only the required read operations, expire no later than the parent grant, and permit further delegation only when explicitly authorized. A parent’s revocation must also invalidate dependent authority through the grant-validation mechanism.
Credential permissions and task authority remain separate. A user-delegated workflow acts on behalf of a person; an unattended workflow may use a service identity’s application permissions. Neither automatically expresses the business restriction “act only within this investigation.”
The analyst may administer thousands of accounts. This assignment authorizes the agent to work within one incident.
2. Verify the proposed action against trusted records
The investigating agent submits a structured tool request:
Example tool request · JSON
{
"request_id": "req-731",
"grant_id": "grant-204",
"incident_id": "INC-4821",
"tool": "identity.disable_account",
"arguments": {
"tenant_id": "tenant-a",
"account_id": "user-1042"
},
"evidence_refs": ["signin-event-883"]
}This is a proposal to disable the account, referencing the investigation’s grant and supporting evidence. It is not proof of permission.
The gateway authenticates the calling agent, validates the request schema, and retrieves current facts:
| Trusted source | What is checked |
|---|---|
| Authorization service | Grant ownership, permitted scope, expiration, and revocation |
| Incident platform | Whether the incident remains open and includes the target |
| Evidence store | Whether the cited events belong to this investigation |
| Identity directory | Account status and privileged role assignments |
| Protected-account inventory | Additional restrictions associated with the account’s business role |
The identity directory is the organization’s authoritative account system. Business-critical classifications may reside in a separate governed inventory.
For INC-4821, these checks confirm that the request is within scope. They also establish that user-1042 is protected and cannot be disabled autonomously.
3. Make the policy decision independently
The policy engine evaluates the proposed action using the verified context.
An illustrative policy expresses the sequence:
Policy logic · illustrative pseudocode
# Illustrative pseudocode using verified context.
if not grant.active or caller.agent_id != grant.agent_id:
return DENY
if not grant.covers(action, tenant, target, incident):
return DENY
if not incident.open or not evidence.verified_for(incident, target):
return DENY
if target.requires_approval:
return REQUIRE_APPROVAL
if not evidence.meets_containment_policy:
return REQUIRE_APPROVAL
return ALLOWThe order matters:
- Outside the delegated scope: Deny.
- Within scope, but requiring independent review: Pause for approval.
- Within scope and eligible for automatic containment: Allow execution after final checks.
Approval does not override missing task authority. Acting against another account requires an authorized scope change.
These checks also do not establish that the agent correctly diagnosed compromise. Evidence requirements and independent review address that uncertainty. Authorization determines what may happen; it cannot guarantee that the underlying judgment is correct.
4. Approve the operation—not the agent
The approval service presents the reviewer with the incident, supporting evidence, protected account, and proposed disablement.
The reviewer approves or rejects this operation against this account, rather than approving the agent generally.
The approval should be explicit:
Action-specific approval
Approval for request req-731
- Action
- Disable account user-1042
- Context
- Incident INC-4821 in tenant-a
- Authorized actor
- The agent associated with grant-204
- Validity
- Until the recorded expiration, unless revoked
- Change rule
- A different target, operation, or material argument requires fresh approval
This approval covers one specific operation under defined conditions. It is not continuing permission for the agent to administer accounts.
The service verifies the reviewer’s authority and protects the approval record. The executor compares the requested action with the approved action before dispatch and tracks its use.
This principle applies beyond the SOC. A finance agent’s approval to pay an invoice should not authorize increasing the amount or changing the beneficiary.
For INC-4821, the reviewer may establish that the executive is traveling and reject disablement. Alternatively, corroborating evidence may justify containment. Either outcome follows an explicit decision boundary.
5. Make the decision binding at execution
The control is incomplete if the agent can bypass the executor and call the identity API directly with equivalent credentials.
Keep consequential access behind trusted execution. Isolate credentials, expose narrowly defined tools, and restrict alternative paths through appropriate network or resource-side controls.
Immediately before dispatch, the executor rechecks grant revocation, approval validity, and relevant resource state. Where supported, conditional API operations help reduce the gap between checking state and changing it.
Execution also needs durable tracking. The executor claims an operation record and associates it with an idempotency key, using downstream idempotency support where available.
If the identity platform times out, the executor reconciles the outcome before retrying. No response does not mean no action occurred.
When required authorization dependencies are unavailable, sensitive writes should pause or fail closed. Separately authorized read-only investigation may continue.
6. Make autonomy measurable for security leaders
For CISOs, the architectural question becomes a business question: how much operational authority is the organization prepared to delegate, and how reliably can it contain the consequences?
Four measures make that discussion concrete:
| Measure | Leadership question |
|---|---|
| Enforcement coverage | Which consequential operations must pass through trusted controls—and which remain bypassable? |
| Autonomous exposure | What accounts, financial amounts, or production services can agents affect without approval? |
| Decision latency | Are approval queues delaying legitimate operations or incident containment? |
| Recovery readiness | How quickly can authority be revoked, uncertain outcomes resolved, and harmful changes recovered? |
Requiring approval for everything creates operational friction. Allowing everything creates uncontrolled exposure. The boundary should reflect business impact, reversibility, and the strength of available evidence.
Preserve the assignment through every action
For INC-4821, the protected audit trail should connect the initiating analyst, agent, delegation grant, evidence, policy version, approval, and confirmed execution outcome. It should exclude access tokens and unnecessary sensitive data.
That trace explains how authority was exercised—not merely which API was called.
The first article established the security boundaries. The second explained why identity alone is insufficient. The control plane connects those boundaries across the path from assignment to action.