Attacks on non-human identity
Techniques that target service accounts, workload identities, and AI agents rather than people: static keys that never rotate, delegation confusion between chained services, and instruction injection against autonomous agents.
Why this control fails
Non-human identities outnumber human ones in most environments and get a fraction of the scrutiny, because they cannot fail a phishing simulation or complain about MFA friction. Service accounts are provisioned with broad permissions to unblock a project, then kept indefinitely because no one is sure what still depends on them. Workload-to-workload calls that chain through multiple services can accumulate combined privilege that no single service was granted on its own. AI agents add a newer failure mode on top of both: an agent that ingests untrusted content can be steered by instructions embedded in that content, so the identity boundary that matters is not just who authorized the agent but what the agent is currently willing to read as a command.
What security people should do
- Assign a named human owner to every service account and workload identity, and treat unowned identities as a deprovisioning queue.
- Replace static, long-lived API keys with short-lived workload credentials issued through a federation or attestation mechanism.
- Scope agent credentials to the specific tools and data an agent needs for one task, and make the grant expire with the task.
- Separate the channel an agent takes instructions from the channel it reads content from, so retrieved content cannot masquerade as a command.
Techniques in this category
A broker sitting between users and a shared backend fails to keep sessions apart, so a token supplied by one caller gets used to serve a different caller's later request, with no attack step beyond timing.
A credential committed to a config file or pasted into a pipeline variable travels with every clone, fork, and log line, and it keeps working for as long as nobody notices it left the vault.
An AI coding agent reads whatever text is in front of it, an issue, a title, a comment, and treats it as instruction. If that runner also holds workflow secrets, the text an anonymous account typed becomes something the credential can execute.
A static API key has no expiry, no built-in scope beyond what was granted at creation, and no way to tell whether the caller presenting it is the workflow it was issued to or whoever found it in a public commit.