Securing AI Agents: Identity, Permissions, and Boundaries

AI agent security is not a prompt problem. It is an authority problem.

A chatbot can produce a bad answer. An agent can turn a bad answer into an email, a code change, an access grant, a financial record, or a containment action. That difference changes the security design. The model is only one component. Identity, policy, tools, data, state, approvals, logs, and stop controls decide whether a mistake stays visible or becomes an operating event.

The practical rule is simple: never ask the model to police its own authority. Treat its plan and arguments as untrusted input. A separate control layer should decide whether the named agent, acting for the named person and purpose, can take the exact action on the exact resource now.

This guide fits inside the Agentic AI Insights hub and the broader secure AI automation service. Use the related AI access control guide for enterprise permission foundations and this guide for the agent specific delegation, action, and revocation problem.

Why AI Agent Security Starts With Authority

An agent usually operates through a loop: observe context, form a plan, choose a tool, submit arguments, receive a result, update state, and continue. Every turn can cross a security boundary. Retrieved content can alter the plan. A tool result can expose a new identifier. Memory can carry stale instructions. A delegated user may lose access while the agent is still running.

Recent public work points in the same direction. NIST AI 800-5 concludes that AI systems create novel security challenges and require existing practices to be adapted. The NCCoE preliminary concept on agent identity and authorization focuses on authentication, authorization, delegation, audit, and nonrepudiation. It is an initial concept, not a final standard, but it names the right operating questions.

The control target is not intelligence. It is the bounded use of authority:

• Identity. Which agent version and environment made the request?
• Delegation. For whom, for what purpose, and until when is it acting?
• Authorization. Is this exact action allowed on this exact resource with these parameters?
• Boundary. Which data, tools, systems, tenants, and destinations are in scope?
• Consequence. What can change, who can be affected, and how difficult is reversal?
• Evidence. Can an operator reconstruct the request, decision, action, result, and approval?

The AI Agent Security Control Surface

Eight surfaces need an owner. Identity binds the workload. Delegation connects the workload to a person or approved service purpose. Policy evaluates requests. Tool controls limit available operations. Data controls constrain sources and destinations. State controls govern memory and retained context. Observation captures decisions and results. Response provides pause, revoke, rollback, and retirement.

A product can cover several surfaces, but no product label proves the design. Ask where the decision is enforced. If a tool description says “do not delete records” but the credential can delete records, the boundary is prose. If an approval asks “continue?” without showing the target and parameters, the approval is weak. If the agent and its operator share one account, attribution is muddy.

GS Agent Authority Exposure Index

GS Consulting built a derived planning model for ten common agent actions. The index combines shared identity exposure, delegation ambiguity, credential persistence, data reach, tool authority, autonomy duration, external effect, reversal difficulty, and audit need. Each input uses a documented 1 to 5 rating. Weighted scores run from 0 to 100.

Security containment ranks highest at 86.4, followed by access grants at 84.4 and financial record updates at 82.0. Repository write and code execution scores 70.0. Email and calendar action scores 61.6. A cited research brief scores 24.0.

The rankings show why “the agent is accurate” is the wrong release criterion. A modest error rate can be tolerable for a draft that receives review. The same rate is unacceptable when the tool can disable an account or change a financial system. Consequence and reversal change the control load.

A limited sensitivity test increased tool authority and external effect weights while reducing autonomy and audit weights. No score moved more than 2.4 points, and the high exposure group remained stable. That does not make the index universal. Replace the ratings with local identity architecture, data classification, tools, workflow duration, and incident history.

The index is a GS Consulting derived planning tool based on cited public sources and analyst assumptions. It is not a NIST score, certification, legal determination, audit result, or substitute for a system risk assessment.

Give Every Agent a Unique Workload Identity

An agent should not borrow a shared human account. Give each deployed agent a workload identity that distinguishes application, version, environment, tenant, and operating owner. Development and production identities should be different. A retired version should no longer authenticate.

Use short duration credentials issued through the organization identity plane where the platform allows it. Keep secrets in a managed store. Remove static tokens from prompts, files, notebooks, and memory. Rotate and revoke credentials through the same operating process used for other workloads.

Identity is necessary but not sufficient. A valid agent can still make an invalid request. Authentication answers who the workload is. Authorization answers whether its current request is allowed. Delegation answers why it is allowed to act for another party.

Carry Delegated Authority With the Request

When an employee asks an agent to act, preserve both identities. The audit record should not replace the person with the agent or replace the agent with the person. Record the requesting person, the agent identity, the approved purpose, the tenant, the task, the resources, the allowed operations, the start, and the expiration.

Do not infer delegation from a chat session alone. A person who may view an invoice may not approve it. A security analyst who may investigate an alert may not disable an executive account. A developer who may draft a change may not merge to production. The agent cannot inherit authority the person does not have, and it should rarely inherit every authority the person does have.

Delegation should narrow authority. It can bind a broad employee role to one case, one repository, one customer, one record set, or one time window. When the user role changes or the task ends, the delegation should expire.

Authorize the Action, Not Just the Tool

A connector allowlist is a start. It is not a permission model. “Can call the ticket system” leaves open whether the agent can read every ticket, alter priority, assign work, close an incident, view restricted attachments, or export a summary.

Evaluate each call against six facts:

1. Principal. Agent identity plus the person or service purpose behind the request.
2. Action. Read, search, draft, route, update, approve, execute, delete, or grant.
3. Resource. Exact tenant, system, repository, record, field, file, or account.
4. Parameters. Destination, amount, recipient, branch, role, command, and other consequential values.
5. Context. Data class, device, location, task, time, risk state, and current session facts.
6. Policy result. Allow, deny, require approval, reduce scope, or stop.

Prefer narrow tools over general shells. A tool that creates a draft change request is safer than a tool that accepts arbitrary commands. Constrain schemas, destinations, file types, row counts, and transaction limits. Validate tool arguments outside the model. Escape or reject content that can cross into another interpreter.

The AI audit trail guide shows how to record tool calls and results. The continuous monitoring guide explains how to watch authority use after release.

Set Data, Tool, State, and Time Boundaries

Prompt injection matters because agents consume instructions from more than the user. Documents, web pages, email, tickets, tool output, and memory can all contain text that tries to redirect the agent. The model may not reliably separate data from instruction. Put the important boundary outside the model.

Use a source allowlist for sensitive workflows. Mark trusted instruction channels. Treat retrieved content and tool output as data. Keep system credentials out of model context. Apply data loss controls to both input and output. Route output to locations that preserve the source sensitivity.

Memory needs its own policy. Define what can be retained, who can retrieve it, how long it persists, how corrections propagate, and how a user or operator can delete it. Do not let one customer, case, or security context contaminate another.

Time is also a boundary. A long running agent can outlive the facts that authorized it. Recheck identity, delegation, policy, and resource state before consequential actions. Set maximum task duration, call count, spending, data volume, and retry limits.

Bind Approval to a Specific Action and Keep a Stop Path

Human approval helps only when the person can see what matters. Show the exact action, target, important parameters, source data, expected effect, reason, alternatives, and expiration. Record who approved, when, under which policy, and whether the executed action matched the approved proposal.

Approval should be mandatory for actions that grant access, change production, move money, make an external commitment, alter an official record, contain a security event, or affect a person. Local policy and consequence may add more cases.

Design revocation before release. Operators need a reliable way to pause the agent, disable one tool, revoke one credential, cancel pending work, isolate state, preserve evidence, and confirm that no queued action remains. The AI agent lifecycle guide covers ownership from registration through retirement.

Six Failure Modes Worth Testing

Identity confusion. Two agents share one credential, or a production event appears under a developer account. Test whether logs preserve both the workload and requesting person.

Delegation drift. The original task ends, but the agent continues to act. Test expiration, role change, and task cancellation.

Prompt injection. A document or tool result asks the agent to reveal secrets or use another tool. Test whether external policy denies the call even when the model requests it.

Excessive tool authority. A simple workflow receives a general command interface. Test blocked commands, targets, parameters, volumes, and destinations.

Memory contamination. One task changes context for another. Test tenant separation, correction, deletion, and stale state.

Failed revocation. A credential is revoked but a queued job or cached token still works. Test pause, revoke, queue cancellation, retry behavior, and confirmation.

The OWASP Top 10 for Agentic Applications provides a useful public threat reference. The NIST CAISI agent security research also shows why empirical testing matters. Neither source removes the need to test the actual tools, permissions, and workflow.

A Practical AI Agent Security Path

1. Inventory agents and owners. Record purpose, environment, model, tools, data, users, owner, status, and retirement date.
2. Map authority. Separate read, draft, route, update, approve, execute, delete, and grant rights for every tool.
3. Issue unique identity. Use workload identity, short duration credentials, managed secrets, and distinct environments.
4. Define delegation. Carry user, purpose, task, scope, constraints, and expiration with each request.
5. Place policy outside the model. Evaluate resource and parameter level rules before tool execution.
6. Gate consequence. Bind human approval to the proposed action and reject changed execution.
7. Test abuse and failure. Exercise injection, stale authority, data escape, repeated calls, revocation, and recovery.
8. Release with observation. Monitor denials, approvals, unusual tools, retry storms, data volume, and incidents.

The Minimum AI Agent Security Evidence Packet

The packet should contain the agent registry and owner, identity configuration, delegation schema, permission policy, tool and resource allowlist, approval design, abuse and failure test results, action and policy logs, monitoring rules, incidents, exceptions, revocation test, and retirement record.

Logs can contain sensitive prompts, data, identifiers, and outputs. Apply access, retention, integrity, and minimization rules to the evidence itself. The goal is not to capture everything forever. It is to preserve the facts required to investigate and govern the workflow.

Sources, Scope, and Planning Caveat

This guide uses public security sources available on July 30, 2026. NIST agent standards work and the NCCoE concept are still developing. Treat preliminary material as direction for planning, not as a final compliance baseline.

• NIST AI 800-5 security considerations summary
• NCCoE preliminary agent identity and authorization concept
• NIST AI Agent Standards Initiative
• NIST SP 800-207 Zero Trust Architecture
• NIST SP 800-53 Revision 5
• NSA, CISA, and partners guidance on agentic AI services
• OWASP Top 10 for Agentic Applications 2026

---

Frequently Asked Questions About AI Agent Security

Related Reading

• Agentic AI Insights hub
• Agentic Workflows Guide
• AI Access Controls and Permission Design
• AI Agent Lifecycle Management
• Continuous Monitoring for AI Agents
• AI Audit Trails and Activity Logging
• Secure AI Automation for Regulated Organizations