Least privilege means giving a system only the access it needs for its task and nothing more. For AI agents, teams usually try to do this with scoped permissions and runtime checks. Those controls depend on one assumption: the system can tell which agent is making a request.

Shared credentials break that assumption. A policy can look strict on paper and still be bypassed in practice if several agents authenticate with the same key.

Why Identity Comes Before Permissions

A permission policy is a set of rules of the form "this identity may perform this action on this resource." Without a distinct identity, there is nothing for the rule to attach to. A shared credential can authenticate a request without identifying which agent sent it, as a recent VentureBeat report points out.

Consider a team that runs an invoice-reading agent and a customer-support agent. If both use one API key, the key must carry the union of both agents' permissions. The invoice agent can now touch support tickets, and the support agent can read invoices, even though the written policy says otherwise.

The same problem affects other controls:

  • Auditing: logs show the key was used, not which agent used it or why.
  • Incident response: if one agent misbehaves or is manipulated by a prompt injection (malicious instructions hidden in content the agent reads), you cannot isolate it without cutting off every agent on that key.
  • Revocation: rotating a shared key disrupts all its users at once, so teams hesitate to do it.

What the Latest Survey Data Shows

The VentureBeat report describes a gap between stated controls and actual practice. Of 40 teams that said they enforce scoped identities and runtime permission checks, 17 also said some or most of their agents still share credentials. In other words, a stated policy and a working policy are not the same thing.

Revocation speed shows a similar picture. Among 102 respondents, 14 named an owner who could revoke an agent's access within minutes. Another 45 said a security or platform team could do it within hours. When ownership is unclear, cutting off a rogue agent becomes a coordination task rather than a switch.

Oversight also seems to trail deployment. A 2026 Gravitee report says only 14.4% of organizations had full IT and security approval for their entire agent deployment. It describes many agents as being deployed at departmental or team level, often bypassing official oversight. Agents launched this way tend to reuse whatever credential is already at hand.

A separate Splunk survey of 2,050 people across ten countries, covered by Help Net Security on October 22, 2026, calls the human checking of agent work a "verification tax." That cost is higher when logs cannot show which agent did what.

Giving Each Agent Its Own Identity

The practical fix is one identity per agent, or even per agent task, with its own narrowly scoped credentials. These are best short-lived and issued by a central system, so revoking one does not affect the others. The details vary by platform, but the pattern is consistent.

The following Python sketch uses only the standard library. It shows why a per-agent token makes a policy enforceable and revocation precise.

import secrets

POLICY = {
    "invoice-agent": {"read:invoices"},
    "support-agent": {"read:tickets", "write:tickets"},
}

# One token per agent, instead of one shared key.
tokens = {name: secrets.token_urlsafe(16) for name in POLICY}
by_token = {token: name for name, token in tokens.items()}


def authorize(token, action):
    agent = by_token.get(token)
    if agent is None:
        print(f"DENY  unknown token action={action}")
        return False
    allowed = action in POLICY[agent]
    verdict = "ALLOW" if allowed else "DENY "
    print(f"{verdict} agent={agent} action={action}")
    return allowed


def revoke(agent):
    by_token.pop(tokens[agent], None)


authorize(tokens["invoice-agent"], "read:invoices")   # allowed
authorize(tokens["invoice-agent"], "write:tickets")   # denied by policy
revoke("invoice-agent")
authorize(tokens["invoice-agent"], "read:invoices")   # denied after revocation
authorize(tokens["support-agent"], "read:tickets")    # unaffected

Every decision names the agent. Revoking the invoice agent leaves the support agent working. With a single shared token, the lookup would return the same identity for every caller, and neither property would hold.

Trade-offs to Expect

Per-agent identity adds operational work. Teams need a way to issue, rotate and expire credentials, and they need to record who owns each agent. Short-lived credentials can also fail mid-task if renewal is not handled well.

Scoping is also hard to get right. Too narrow, and agents fail in ways that are tedious to debug. Too broad, and the identity exists but the privilege is not really least. Teams often start broad and tighten as logs reveal what each agent actually uses, which is only possible when logs are per agent.

Conclusion

Least privilege for agents is an identity problem before it is a policy problem. If several agents share one credential, scoped rules, audit trails and fast revocation all lose their footing, however good the policy document looks.

The survey figures suggest many teams are in exactly this position: they enforce permissions in principle while sharing credentials in practice. Giving each agent a distinct, short-lived identity with a named owner is the step that makes the rest of the controls meaningful.