What breaks when organisations focus only on what an AI system can access and ignore what it is allowed to do?

Why This Matters for Security Teams

When security teams focus only on what an AI system can access, they miss the more dangerous question: what can it be induced to do with that access? That gap turns legitimate permissions into operational authority for prompt injection, tool chaining, data exfiltration, and destructive actions. The control problem is no longer just identity and entitlement, but action-level governance at runtime, as reflected in the OWASP Non-Human Identity Top 10 and NHIMG’s Ultimate Guide to NHIs.

This matters because autonomous systems do not follow stable human-like access patterns. An agent can start with a narrow task, chain tools, retrieve secrets, call external services, and pivot into actions no reviewer predicted when the permission was granted. The result is over-permissioned behaviour, not just over-permissioned accounts. NIST controls such as NIST SP 800-53 Rev 5 Security and Privacy Controls help, but they do not solve the core issue unless the organisation also governs what the system is allowed to do at the moment of action.

In practice, many security teams encounter agent abuse only after a tool call, data leak, or unintended workflow execution has already occurred, rather than through intentional design review.

How It Works in Practice

The practical fix is to separate access from authority. Access says what an AI system can technically reach. Authority says what it may do, under which conditions, and with what approvals. For agentic workflows, that means pairing workload identity with runtime policy, short-lived credentials, and explicit execution boundaries. Current guidance suggests treating the agent as a distinct workload identity, not a user proxy, and issuing ephemeral permissions only for the task at hand.

That model is increasingly aligned with NHIMG’s 52 NHI Breaches Analysis, which shows how credential exposure and misuse become systemic once secrets are treated as durable trust. It also matches implementation patterns discussed in the DeepSeek breach, where access to sensitive material created downstream risk far beyond the initial compromise.

Practitioners should look for these controls:

• JIT credentials with strict TTLs so the agent only holds secrets for the current action.
• Action-level allowlists that distinguish read, write, delete, transfer, and approve operations.
• Runtime policy evaluation using policy-as-code so decisions reflect context, not static role membership.
• Step-up approval for irreversible actions, especially money movement, deletion, and privilege changes.
• Comprehensive logs that record intent, tool calls, policy decisions, and outputs for each step.

This is where identity primitives such as SPIFFE or OIDC-style workload tokens become important: they prove what the agent is, while policy determines what it may do right now. Best practice is evolving, but most mature designs now combine per-task credential issuance with a broker or guardrail layer that can deny unsafe actions even when the underlying system has network reach and authenticated access. These controls tend to break down in loosely governed multi-agent pipelines because one agent’s sanctioned output can become another agent’s implicit approval path.

Common Variations and Edge Cases

Tighter action controls often increase operational overhead, requiring organisations to balance safety against latency, developer friction, and workflow complexity. That tradeoff becomes sharper when agents must act across SaaS platforms, internal APIs, and human-in-the-loop queues. There is no universal standard for this yet, so teams should expect to tune policy boundaries as they learn which actions are benign, which are reversible, and which require explicit approval.

One common edge case is read-only access that still produces harm. An agent with harmless-looking retrieval rights can be manipulated into summarising secrets, exposing customer data, or constructing follow-on attacks from legitimate context. Another is delegated execution: a system may never hold a powerful token directly, but it can trigger a workflow that does. That is why “can access” is an incomplete control objective.

Vendor documentation often emphasises content moderation or prompt filtering, but those are insufficient on their own. The stronger pattern is to enforce bounded capabilities, log every tool invocation, and revoke authority immediately after task completion. NHIMG’s Microsoft SAS Key Breach is a useful reminder that once credential power is broad, the blast radius expands quickly. For deeper context, Ultimate Guide to NHIs — Key Challenges and Risks frames why static trust assumptions fail when identities are machine-driven.

Related resources from NHI Mgmt Group

• What breaks when organisations focus on the model but ignore the surrounding AI environment?
• What breaks when organisations protect AI models but ignore SaaS access and OAuth controls?
• What breaks when organisations copy legacy access into a new ERP system?
• What breaks when organisations do not map the access path of AI and SaaS integrations?