What do teams get wrong about zero trust for service accounts and agents?

Why This Matters for Security Teams

zero trust fails quickly when teams apply it only to humans and leave service accounts or agents on permanent trust paths. Those identities often run pipelines, call APIs, and chain privileges across systems, so any standing credential becomes a durable blast-radius multiplier. Current guidance suggests that zero trust must extend to the identity, the request context, and the transaction, not just the network boundary. That is especially important for agentic workloads, where behavior changes with goals and tool access.

NHIMG research shows the scale of the problem: Ultimate Guide to NHIs — 2025 Outlook and Predictions reports that 90% of IT leaders say properly managing NHIs is essential for a successful zero-trust implementation. That aligns with the reality that service accounts are not a side issue; they are often the highest-privilege identities in the estate. Standards bodies reinforce this shift through NIST SP 800-207 Zero Trust Architecture and the emerging agent-focused guidance in OWASP Top 10 for Agentic Applications 2026.

In practice, many security teams encounter abuse of a “temporary” service account only after lateral movement or data exfiltration has already occurred, rather than through intentional zero-trust design.

How It Works in Practice

For service accounts and agents, zero trust is less about a perimeter and more about continuous, context-aware authorization. That means the identity must be strongly established, the request must be evaluated at runtime, and the credential must be constrained to a narrow purpose. For agents, the emerging best practice is to treat the workload identity as the primitive, not the long-lived secret. Workload identity standards such as SPIFFE and SPIRE help prove what the workload is, while policy engines decide what it may do for this specific task.

In practical terms, teams should separate authentication from authorization and move from static roles to intent-based controls. A task-specific access decision can combine the workload identity, source environment, requested action, data sensitivity, and session duration. For example:

• issue short-lived credentials per task instead of reusing static API keys;
• bind access to workload identity and service attestation where possible;
• evaluate policy at request time using policy-as-code;
• revoke or let credentials expire automatically when the task completes;
• log each decision so access can be traced back to the initiating workload and business intent.

That approach maps well to the guidance in Guide to SPIFFE and SPIRE, which is useful when teams need a cryptographic identity layer for workloads, and to NIST AI Risk Management Framework, which emphasizes measurable governance and operational accountability. The core mistake is assuming an agent or service account has a stable access profile; autonomous systems do not, and their requests can shift as they chain tools or pursue goal completion.

These controls tend to break down in legacy environments with shared credentials, coarse RBAC, and no reliable workload telemetry because the policy engine cannot distinguish one execution context from another.

Common Variations and Edge Cases

Tighter zero-trust control often increases operational overhead, requiring organisations to balance stronger containment against deployment speed and incident-response simplicity. That tradeoff is real, especially where old systems cannot issue short-lived tokens or do fine-grained authorization.

One common edge case is batch jobs and integration services that appear non-interactive but still perform high-impact actions. Current guidance suggests these should still move to ephemeral credentials and explicit policy checks, but there is no universal standard for how quickly every environment must rotate or revoke them. Another case is multi-agent orchestration, where one agent delegates to another. In those environments, the question is not just whether the first agent is trusted, but whether downstream tool calls remain within the original intent.

Teams also get this wrong when they equate “no user” with “low risk.” NHIMG data shows that excessive privilege remains widespread, and standing access is especially dangerous when secrets are exposed in code or CI/CD paths. The risk is compounded by agentic systems that can adapt their sequence of actions in ways human operators did not predefine. Relevant analysis in AI LLM hijack breach and the vendor-agnostic CSA MAESTRO agentic AI threat modeling framework both point to the same operational lesson: zero trust for service accounts and agents must be designed around runtime behavior, not assumed trustworthiness.

Best practice is evolving, but the direction is clear: remove standing privilege, shorten credential lifetime, and require every non-human request to prove both identity and purpose.

Related resources from NHI Mgmt Group

• What do security teams get wrong about measuring Zero Trust programmes?
• What do security teams get wrong about ownership for service accounts and tokens?
• What do security teams get wrong about shadow accounts and unmanaged identities?
• What do security teams get wrong about Zero Trust and identity governance?