What breaks when agents are given personal access tokens and service account keys directly?

Why This Matters for Security Teams

Giving an agent personal access tokens or service account keys collapses identity, privilege, and execution into one opaque runtime. That is dangerous because autonomous software does not behave like a human user with a fixed job description. It can chain tools, retry failed actions, and follow prompts into workflows the original issuer never anticipated. The control problem is therefore not just secret storage, but the loss of revocation discipline, traceability, and separation of duty.

This is exactly the pattern called out in OWASP NHI Top 10 and in the OWASP Agentic AI Top 10: static credentials create a durable blast radius that follows the agent wherever it runs. The risk is not theoretical. GitGuardian reported that 24,008 unique secrets were exposed in MCP configuration files in 2025 alone, showing how quickly agent tooling can become a secrets distribution layer rather than a control layer. In practice, many security teams encounter this only after a token has already been reused across multiple tools and environments, rather than through intentional access design.

How It Works in Practice

Agents should not be handed standing credentials unless there is no alternative. Current guidance suggests a better pattern is workload identity plus just-in-time authorisation: prove what the agent is, decide what it may do at request time, issue a short-lived credential for that one task, then revoke it automatically. That means the agent process authenticates as a workload, not as a person, and its permissions are evaluated against context such as target system, task intent, risk score, and time window. For agentic systems, this is closer to intent-based authorisation than classic RBAC.

In practical terms, teams should separate three layers. First, use workload identity such as OIDC-based federation or SPIFFE-style identity so the platform can distinguish one agent instance from another. Second, enforce policy at the moment of action using policy-as-code, with CSA MAESTRO agentic AI threat modeling framework and NIST AI Risk Management Framework as the governance backbone. Third, issue JIT secrets with the shortest workable TTL and revoke them when the task completes. That is especially important where secrets are already showing up in agent ecosystems, as seen in the Salesloft OAuth token breach and the Moltbook AI agent keys breach.

For control design, use NIST AI Risk Management Framework to document ownership, Guide to the Secret Sprawl Challenge for lifecycle discipline, and monitor for reuse across toolchains. These controls tend to break down when agents are allowed to invoke legacy systems that only accept long-lived static keys because the platform cannot enforce task-scoped revocation end to end.

Common Variations and Edge Cases

Tighter credential controls often increase orchestration overhead, so organisations have to balance operational speed against containment. That tradeoff matters most when agents run across multiple SaaS platforms, CI/CD runners, or nested workflows that were never designed for ephemeral identity.

There is no universal standard for this yet, but best practice is evolving toward replacing personal access tokens with workload-scoped access, short TTLs, and runtime policy checks. Some environments still need service account keys for interoperability, yet those should be wrapped in vault-issued leases, narrow scopes, and strong audit trails rather than embedded directly in prompts, env vars, or agent memory. If the agent is allowed to initiate actions in third-party systems, the answer also has to include human escalation paths and automatic kill switches, because autonomous behaviour can expand faster than the policy author anticipated.

For that reason, the same lesson appears repeatedly across incident reporting and research: once secrets become portable runtime inputs, revocation becomes advisory instead of effective. Entro reported that 44% of NHI tokens are exposed in the wild, which aligns with the broader pattern seen in JetBrains GitHub plugin token exposure and the Analysis of Claude Code Security. The practical takeaway is simple: if an agent can hold a secret directly, it can usually reuse it more broadly than intended, especially in systems with weak segmentation or shared runners.

Related resources from NHI Mgmt Group

• Should organisations prioritise runtime monitoring or access scoping for agents?
• How should security teams decide whether JIT access is safe for non-human identities?
• What is the difference between JIT access and Zero Trust for NHIs?
• Why do Active Directory service accounts complicate zero trust programs?