How should teams approach authorization for AI systems that invoke tools and data?

Start by distinguishing bounded automation from genuine autonomy, then decide which actions need live authorization before execution. Use context-aware policies for tool use, data access, and escalation paths, and avoid assuming a pre-approved workflow will stay safe as the system scales. The governance model must match the runtime behaviour, not the label.

Why This Matters for Security Teams

Authorization for AI systems that invoke tools and data is not a simple extension of human access control. Once an agent can choose actions, chain tool calls, and request data on demand, static RBAC stops describing real risk. Current guidance suggests the control point must move from pre-approved workflow design to runtime decision-making, especially when secrets, customer data, or privileged APIs are involved. NIST’s NIST SP 800-53 Rev 5 Security and Privacy Controls remains useful for access governance, but agentic systems require sharper context than a normal application session.

This is where teams often underestimate exposure. A tool-using model can make a harmless-looking request first, then use returned output to justify a more sensitive follow-up, including lateral movement across systems. NHIMG research on the Ultimate Guide to NHIs shows how quickly secret abuse and control gaps can become operational incidents when identities and secrets are not tightly governed. In practice, many security teams encounter unsafe agent behaviour only after a tool chain has already executed, rather than through intentional authorization review.

How It Works in Practice

Effective authorization starts by separating what the system may do from what it is allowed to do right now. For bounded automation, teams can define fixed workflows with narrow permissions. For genuine autonomy, the safer pattern is intent-aware authorization: each tool call, data lookup, or escalation request is evaluated at runtime using the agent’s purpose, current context, data sensitivity, and risk score. That means policy-as-code, not hard-coded approval paths.

Workload identity is the foundation for this model. Instead of treating the agent as a user, teams should identify the workload cryptographically and attach short-lived credentials to a specific task or session. SPIFFE-style workload identity, OIDC-based service tokens, and just-in-time issuance all support a tighter model where access expires quickly and is revoked automatically after task completion. This limits the blast radius if the agent loops, retries, or is prompted into unexpected behaviour.

• Authorise the tool, not just the application, so each action has a distinct policy check.
• Bind decisions to context such as request origin, data class, and sensitivity of the target system.
• Use short TTL secrets and ephemeral tokens rather than standing credentials.
• Log the decision path, including why a call was allowed or denied, for later review.

This approach aligns with modern identity guidance and with NHIMG’s research on how NHIs become abuse points when secrets and permissions are too durable. The DeepSeek breach is a reminder that once sensitive data and credentials are exposed in the agentic supply chain, authorization alone cannot compensate for weak containment. These controls tend to break down when multiple tools share the same broad service identity because the policy engine can no longer distinguish one safe action from the next risky one.

Common Variations and Edge Cases

Tighter authorization often increases latency and operational overhead, so organisations have to balance safety against user experience and system throughput. Best practice is evolving, and there is no universal standard for agent authorization yet, especially where multiple models, tools, and third-party APIs are composed into one workflow.

One common edge case is delegated access. If an agent acts on behalf of a user, the system should preserve user intent without inheriting unrestricted downstream rights. Another is retrieval-heavy systems: read access to a vector store may seem low risk, but retrieved content can still leak secrets or sensitive policy text into follow-on tool requests. A third edge case is escalation paths. If an agent can request elevated permissions, that path needs stricter review than ordinary reads, ideally with separate policy conditions and shorter-lived grants.

NHIMG’s The State of Secrets in AppSec highlights a broader operational problem: organisations often believe their controls are stronger than they are. For agentic systems, that mismatch is especially dangerous because the system can act faster than reviewers can intervene. The practical rule is simple: if the agent can initiate it, the authorization decision must be just as dynamic as the action itself.

Related resources from NHI Mgmt Group

• How should security teams implement ISO 42001 certification for AI systems that use customer data and third-party tools?
• How should security teams assess whether compliance tools are enough when sensitive data moves across SaaS, cloud, and AI systems?
• How should security teams handle risks from AI browser extensions?
• How should organizations approach the governance of AI agents?