They complicate shared responsibility because the provider can secure the platform, but it cannot own the business decision to let an agent read mail, query systems, or trigger actions. Once behaviour is runtime-driven, the enterprise is accountable for permissions, content handling, monitoring, and regulatory fit.
Why Traditional Shared Responsibility Breaks Down for AI Agents
Shared-responsibility models were built for platforms, not autonomous software entities with execution authority. A cloud provider can secure the infrastructure, but it cannot decide whether an agent should read mail, query a CRM, call an API, or trigger a payment. That decision belongs to the enterprise, which means the business owns the risk when the agent behaves outside the expected path. NHI Management Group’s OWASP NHI Top 10 and OWASP’s OWASP Agentic AI Top 10 both reflect the same reality: once an agent can chain tools, the control problem shifts from infrastructure hardening to runtime governance.
This is why current guidance increasingly treats agentic workloads as a distinct class. In SailPoint’s AI Agents: The New Attack Surface report, 80% of organisations said their AI agents had already performed actions beyond intended scope, which is a strong signal that the failure mode is not hypothetical. In practice, many security teams encounter this only after an agent has already accessed data or executed an action that no one expected at design time.
How Shared Responsibility Becomes Runtime Responsibility
For human users, shared responsibility is usually managed with RBAC and pre-defined roles. For agents, that model is too static. An AI agent is goal-driven, so its access needs change with each task, prompt, tool call, and downstream system it touches. Best practice is evolving toward intent-based authorisation, where the policy engine evaluates what the agent is trying to do at runtime rather than assuming a fixed access pattern. That aligns well with policy-as-code approaches described in the NIST AI Risk Management Framework and the CSA MAESTRO agentic AI threat modeling framework.
Operationally, that means the enterprise should treat the agent as a workload identity, not as a user. The practical stack usually includes short-lived credentials, JIT provisioning, and automatic revocation after a task completes. A long-lived secret is dangerous because an agent can reuse it across prompts, tools, and sessions, which makes compromise durable and hard to trace. When a control plane supports cryptographic workload identity, such as SPIFFE/SPIRE or OIDC-based proof of workload identity, the organisation can bind a specific action to a specific agent instance rather than to a broad service account.
- Issue ephemeral credentials per task, not broad standing access.
- Evaluate authorisation at request time using context, intent, and destination system.
- Log tool use, data access, and downstream actions as audit events, not just model outputs.
- Revoke secrets automatically when the task, session, or trust boundary changes.
This guidance breaks down in environments that still rely on shared service accounts, legacy middleware, or manually approved break-glass access because the agent cannot be cleanly tied to a single, reviewable identity.
Where Accountability Gaps Usually Appear
Tighter control often increases operational overhead, so organisations have to balance reduced blast radius against slower automation and more policy maintenance. That tradeoff becomes visible in multi-agent workflows, delegated tool chains, and regulated data handling, where one agent’s output becomes another agent’s input. In those environments, “who is responsible?” is not the same as “who ran the model?” The better question is who approved the use case, who owns the policy, and who can prove the control operated at runtime.
There is no universal standard for this yet, but the direction is consistent across the OWASP Top 10 for Agentic Applications 2026, NIST AI Risk Management Framework, and NHI governance work from NHIMG. The hardest edge case is autonomous escalation: an agent starts with a harmless task, then chains tools, copies data, or requests new privileges because its objective changed. NHIMG’s Top 10 NHI Issues and Ultimate Guide to NHIs – Regulatory and Audit Perspectives both emphasise that auditability matters as much as access design.
Current guidance suggests that enterprises should define explicit agent owners, scope boundaries, approval thresholds, and post-action review requirements before deployment. Without those, shared responsibility becomes shared ambiguity, and that is usually where the first compliance finding appears.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
OWASP Agentic AI Top 10 and CSA MAESTRO address the attack and risk surface, while NIST AI RMF set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| OWASP Agentic AI Top 10 | A1 | Agentic apps need runtime controls for unpredictable tool use and escalation. |
| CSA MAESTRO | MAESTRO focuses on modeling agent threats, trust boundaries, and control gaps. | |
| NIST AI RMF | AI RMF frames accountability, governance, and ongoing risk management for agents. |
Use intent-aware policies and per-action checks before any agent tool call or external side effect.
