Verified intelligence · Expert-reviewed from public records, platform data, primary sources, and private research beyond AI search.
AGENTSTechnologyGLOBAL
AI agent security, identity and permissions
Agent risk now sits in identity and delegated authority. Buyers should approve the credentialed route, not the agent brand, before write access, browsing, code execution or MCP tools move into production.
The colophon
- Landscape reviewed
- 2026-06-13
- Latest revision
- 2026-06-13
- Kinetics
- Kinetics: hotImpact 0.93 · momentum 0.87 · vector 0.8110 balls · 58 px/s
AI agents are moving from answer generation into tool execution, delegated user action, service-account authority and cross-agent communication, which makes identity and permission design the production control. Protocol, non-human identity and browser/tool execution guidance are changing approval evidence faster than annual access-review cycles.
- To watch
- 5 August 2026: Black Hat USA 2026 Briefings open; agent-tool, prompt-injection, identity or cloud-runtime research could add negative tests to MCP, browser, sandbox and service-role approvals.
- 7 August 2026: Cloud Village at DEF CON 34 opens; cloud identity, metadata-service, VPC, egress or managed-service-agent research could tighten hosted-agent and AgentCore approval packets.
- 6 August 2026: Robotic Hacking Community at DEF CON 34 opens; physical-AI and robotics security work could move action-capable agents from software-only approval into fail-safe, operator and hardware-permission tests.
- 14 August 2026: Black Hat USA 2026 recorded briefings become available; white papers or replayed sessions may expose new exploit details that warrant route reapproval before September access reviews.
- Known unknowns
- No public benchmark yet tests the same enterprise route across user-delegated OAuth, agent identity, service roles, MCP tools, A2A delegation, browser access, code execution, egress, human approval, rollback and SIEM export.
Contents
- Executive summary
- Identity route register
- Delegation and token boundary
- Protocol and tool boundaries
- Platform control surfaces
- Control-plane directory
- Incident and exploit patterns
- Prompt-injection and tool evals
- Sandbox, egress and recovery
- Operating model
- Workflow route playbooks
- Approval economics
- Contract and procurement proof
- Reapproval triggers
- Known unknowns
- Recommended next steps
- Source ledger
- Glossary
Executive summary
Credentialed routes set the approval boundary. Agent security approval now starts with the credentialed action path: who the agent acts as, what token it uses, which tool it can call and how a failed action is revoked. A chat agent can be wrong. A tool-using agent can be wrong and spend money, send data, update a record, browse with a user's cookies, execute code or call another agent. The buying question has therefore moved from model safety to identity route approval, with governance, mapping, measurement and management attached to the action path 8.
The route is the approved chain from human intent to accepted action: user identity, agent identity, token, tool, data boundary, reviewer, log record, rollback and reapproval trigger. That chain is now visible in public standards and provider documents, but no single vendor owns it end to end 3,15.
The immediate decision is simple: keep broad agents read-only until each action has a credentialed route. Delegated user actions must stay inside user permission. App-only or service-role authority needs its own owner, scope and revocation path. Browser, code and MCP tools need hostile-content tests before they see sensitive accounts or production systems 4,26.
Identity is the economic and legal unit of agent approval. A route with weak attribution cannot prove accepted work, allocate liability, price risk or survive an incident review.
Approval should be route-specific, not vendor-wide. A provider can be approved for one route and blocked for another.
Agent authority approval tree
Classify the authority before choosing the agent stack.
Will the agent only read approved sources and return a draft answer?
YesAllow after source, identity and log checks.
NoClassify the action path.
Next: Q2Will it draft, stage, summarize or propose a record change?
YesRequire reviewer assignment, diff view, source record and no execution without acceptance.
NoCheck whether it can write or execute.
Next: Q3Can it write records, send messages, browse as a user, execute code, call tools or invoke another agent?
YesRequire scoped identity, token-audience proof, tool schema, human approval and rollback evidence.
NoKeep as monitored read/draft route.
Can the route touch secrets, payments, admin settings, regulated data or external commitments?
YesBlock by default; approve only after security review, private eval, log export and incident drill.
NoPilot with bounded scopes and reapproval triggers.
Classified authority becomes proof gating. Once authority is classified, approval turns on proof: identity owner, token audience, tool schema, sandbox boundary, log export, reviewer gate and rollback path 3,15. Browser, code and remote-tool routes need hostile-content and token-boundary proof before approval moves beyond a pilot 4,26.
The first approval decision
| Route | Default decision | Proof that changes approval |
|---|---|---|
| Read-only agent over approved sources | Approve for pilot | Agent identity, source boundary, data-class rule, answer log, blocked write tools and no-answer behaviour. |
| User-delegated SaaS action | Approve narrowly | OAuth grant, user consent, user permission inheritance, token audience, approval record and revoke drill. |
| Agent identity with app-only authority | Security review | Owner, RBAC role, scope, service role, log export, access review and explicit break-glass rule. |
| MCP or A2A tool route | Conditional | Protected-resource metadata, tool schema, token validation, server trust, SSRF controls and tool-poisoning eval. |
| Browser, shell or code execution | Block until isolated | Sandbox boundary, egress policy, credential injection design, metadata-service block, snapshot and rollback evidence. |
Identity route register
Every approved action needs an identity record, a permission record and an evidence record. The route register is the minimum viable control plane. Most agent failures will not look like a model refusing a safety policy. They will look like ordinary access: a token reused for the wrong tool, a service role with broad storage rights, a user-delegated action that writes more than the user expected, or an agent acting through a shared account that nobody can disable cleanly.
The register turns those failures into answerable questions. Who owns the agent? Which identity authenticates? Is the action delegated from a human or app-only? Which resource is the token for? What fields can be read or written? Who approved the action? What log proves it happened? What revokes it?
Public signals are moving in the same direction. Entra Agent ID treats agents as a distinct identity type with sign-in and audit surfaces, and Foundry separates delegated and app-only flows 15,16. Salesforce maps agents to profiles and permission sets, while Auth0 token vaulting keeps external provider tokens out of application code 28,21.
The weak route is the one that says the agent runs as a generic service account, user token, browser session or local process. That may be acceptable in a demo. It is a poor production identity unless every use is narrow, logged and revocable.
What the register should capture
| Register field | Accepted answer | Weak answer |
|---|---|---|
| Agent identity | Distinct identity, owner, sponsor, lifecycle status and disable path. | Borrowed human account or shared API key. |
| Authority mode | Delegated user, agent principal, service role or agent-to-agent route named separately. | The agent has access. |
| Resource scope | Audience, role, object, field, API, file path and environment boundaries named. | Workspace or tenant access. |
| Tool schema | Typed action, parameter constraints, allowed data class and blocked parameter set. | Natural-language tool instructions only. |
| Approval gate | Automatic, reviewer-approved, security-approved or blocked by action class. | Prompt says be careful. |
| Evidence record | User, agent, token/resource, tool, input, output, reviewer, result and rollback fields exportable. | Conversation transcript only. |
Register fields become approval posture. The register names the identity, scope, tool and evidence fields. The authority matrix converts those fields into a default gate by action class, so read, draft, write, execute and admin routes do not receive the same approval.
Identity route changes the approval gate
Read the cell as the default approval posture before private evals.
Glossary
Terms used in this report
| Term | Plain meaning |
|---|---|
| Route | The approved path from work to accepted output: source set, data boundary, model or vendor channel, tools, reviewer, evidence record and reapproval trigger. |
| API | Application programming interface: a governed software connection used by an app or workflow to call a model or service. |
| SDK | Software development kit: packaged code and tools developers use to connect a product to an API or service. |
| LLM | Large language model: a model trained to read and generate text-like tokens. |
| Token | A chunk of text used for billing, context windows and rate limits. It is usually smaller than a word, not a page count. |
| RAG | Retrieval-augmented generation: search approved sources first, then pass selected evidence into the model. |
Definitions are reader aids, not separate evidence claims.
MCP PREVIEW INVENTORY
What the locked report contains
Agent risk now sits in identity and delegated authority. Buyers should approve the credentialed route, not the agent brand, before write access, browsing, code execution or MCP tools move into production.
Schema endpoints
- Sample object: /api/v1/reports/RPT_01KSKSECAGENTIDPERMS01/sample
- Inventory object: /api/v1/reports/RPT_01KSKSECAGENTIDPERMS01/inventory
- Schema contract: /api/v1/reports/RPT_01KSKSECAGENTIDPERMS01/schema
Coverage fields
- Category: AGENTS
- Sector: Technology
- Region: GLOBAL
- Topics: AI agent security, agent identity, agent permissions, non-human identity, MCP security, A2A protocol, OAuth delegation, tool guardrails, prompt injection, workload identity, agent audit logs, agent procurement
Schema contract
- Contract: colophon.report_document v2026-05-28
- Payload schemas: document, summary, sample, inventory, full_report
- Required top-level fields: title, subtitle, abstract, category, sector, region, topics, sources, evidence, claims, colophon, body
- Integrity rules: evidence.sourceId must reference sources[].id claim.evidenceIds[] must reference evidence[].id evidence.claimIds[] must reference claims[].id section and block evidence references must resolve colophon.kinetics.speed must match the momentum band for the business impact x momentum model
Data-point inventory
- vendor_or_actor_ledger: entity names; product categories; source references; confidence notes
- buyer_decision_fields: pricing signals; deployment constraints; risk flags; monitoring fields
- evidence_index: source class; access date; claim linkage; verification status
Section inventory
- 1. Executive summaryPreview
decision-ready conclusions; major findings; confidence caveats
- 2. Identity route registerPreview
structured findings; supporting evidence; buyer-use fields
- 3. Delegation and token boundaryLocked
structured findings; supporting evidence; buyer-use fields
- 4. Protocol and tool boundariesLocked
structured findings; supporting evidence; buyer-use fields
- 5. Platform control surfacesLocked
structured findings; supporting evidence; buyer-use fields
- 6. Control-plane directoryLocked
structured findings; supporting evidence; buyer-use fields
- 7. Incident and exploit patternsLocked
structured findings; supporting evidence; buyer-use fields
- 8. Prompt-injection and tool evalsLocked
structured findings; supporting evidence; buyer-use fields
- 9. Sandbox, egress and recoveryLocked
structured findings; supporting evidence; buyer-use fields
- 10. Operating modelLocked
structured findings; supporting evidence; buyer-use fields
- 11. Workflow route playbooksLocked
structured findings; supporting evidence; buyer-use fields
- 12. Approval economicsLocked
structured findings; supporting evidence; buyer-use fields
- 13. Contract and procurement proofLocked
structured findings; supporting evidence; buyer-use fields
- 14. Reapproval triggersLocked
structured findings; supporting evidence; buyer-use fields
- 15. Known unknownsLocked
structured findings; supporting evidence; buyer-use fields
- 16. Recommended next stepsLocked
structured findings; supporting evidence; buyer-use fields
- 17. Source ledgerLocked
normalized entity rows; source ledger; evidence-to-claim mapping
- 18. GlossaryPreview
structured findings; supporting evidence; buyer-use fields
Relevance signals
- Confidence score: 0.89
- Source classes: security_framework, protocol_specification, security_standard, identity_standard, government_framework, government_security_standard, threat_model_framework, industry_survey, identity_platform_docs, cloud_agent_docs, security_guidance, agent_platform_docs, security_research, workload_identity_standard, agent_framework_docs, model_system_card, agent_index, agent_benchmark, government_security_guidance, research_paper, cloud_docs, conference_schedule
- Known unknowns: No public benchmark yet tests the same enterprise route across user-delegated OAuth, agent identity, service roles, MCP tools, A2A delegation, browser access, code execution, egress, human approval, rollback and SIEM export.
- Watch signals: 5 August 2026: Black Hat USA 2026 Briefings open; agent-tool, prompt-injection, identity or cloud-runtime research could add negative tests to MCP, browser, sandbox and service-role approvals. 7 August 2026: Cloud Village at DEF CON 34 opens; cloud identity, metadata-service, VPC, egress or managed-service-agent research could tighten hosted-agent and AgentCore approval packets. 6 August 2026: Robotic Hacking Community at DEF CON 34 opens; physical-AI and robotics security work could move action-capable agents from software-only approval into fail-safe, operator and hardware-permission tests. 14 August 2026: Black Hat USA 2026 recorded briefings become available; white papers or replayed sessions may expose new exploit details that warrant route reapproval before September access reviews.
Locked continuation
Purchase or subscribe to unlock the full findings, evidence ledger, and buyer-ready recommendations.