How should security teams govern AI agent access when protocols leave authorization open-ended?

Why This Matters for Security Teams

When protocols leave authorization open-ended, the protocol becomes a transport layer, not a control plane. That distinction matters because AI agents are goal-driven: they can chain tools, retry actions, and pivot across systems in ways static role design does not anticipate. Security teams that assume the protocol will “handle auth” often end up with broad, persistent delegation that outlives the task, the context, and sometimes the business need.

Current guidance suggests treating agent access as a runtime governance problem, aligned to policies and telemetry rather than to message syntax. That means defining purpose, scope, data boundaries, and expiry before an agent is allowed to act, then enforcing those limits continuously as context changes. This is consistent with the direction of the OWASP Agentic AI Top 10 and the NIST AI Risk Management Framework, both of which emphasise context, governance, and accountable controls over implicit trust.

NHI Management Group’s The State of Non-Human Identity Security shows why this gap persists: only 1.5 out of 10 organisations are highly confident in securing NHIs, while over-privileged accounts remain a major attack cause. In practice, many security teams encounter agent overreach only after a tool chain has already been abused, rather than through intentional design.

How It Works in Practice

The practical model is to separate protocol from policy. A protocol such as MCP can standardise request and response structure, but an external authorisation layer must decide whether the agent may perform the action at all. That decision should happen at request time, with context such as user intent, task purpose, target resource, environment, data sensitivity, and current risk signals.

For autonomous workloads, best practice is evolving toward intent-based authorisation, short-lived delegation, and workload identity. The agent should prove what it is through cryptographic identity, not through a reused human credential. Where possible, use workload identity primitives such as SPIFFE/SPIRE or OIDC-backed service identity, then issue just-in-time credentials that expire automatically when the task completes. This reduces the blast radius if the agent is redirected, looped, or prompted into an unsafe action.

A workable control pattern usually includes:

• Policy-as-code evaluated at runtime, using engines such as OPA or Cedar.
• Ephemeral tokens with narrow scope and short TTLs, not standing secrets.
• Allowlists for tools, data classes, and resource tiers that the agent may touch.
• Continuous logging of every agent action, including tool calls and delegated sub-actions.
• Revocation paths for task completion, policy drift, or anomalous behaviour.

This approach maps closely to the risks highlighted in AI Agents: The New Attack Surface, where 80% of organisations reported agents acting beyond intended scope. It also aligns with the CSA MAESTRO agentic AI threat modeling framework, which treats agent behaviour as dynamic and threat-prone rather than deterministic. These controls tend to break down when agents inherit broad SaaS admin roles or direct database credentials, because the protocol can no longer constrain downstream tool chaining.

Common Variations and Edge Cases

Tighter runtime authorisation often increases operational overhead, requiring organisations to balance safety against latency, engineering complexity, and user experience. That tradeoff is real, especially when multiple agents collaborate or when a workflow needs delegated access across several systems.

There is no universal standard for this yet. Some environments can rely on central policy enforcement at the orchestration layer, while others need policy checks inside each tool boundary. In highly regulated or high-impact workflows, the safer pattern is to require fresh authorisation for each material step rather than a single broad grant. In lower-risk automation, a constrained session token with a narrow scope may be acceptable if the expiry is short and the audit trail is complete.

Edge cases appear when the agent acts on behalf of a human but also initiates sub-tasks independently. In those cases, the control question is not just “who approved the session?” but “which actions were authorised, for which data, under what conditions, and for how long?” That is why open-ended protocol support should be paired with NHI governance, not substituted for it. The Ultimate Guide to NHIs and the OWASP Non-Human Identity Top 10 both reflect the same practical principle: entitlement must be bounded, observable, and revocable.

Related resources from NHI Mgmt Group

• How should security teams govern API keys used for generative AI access?
• How should security teams govern non-human identities that have persistent access?
• How should security teams govern AI agent authorization in distributed systems?
• How should security teams govern AI agent access without relying only on behavioral monitoring?