Ask a security team to inventory who can access production, and they'll show you a list of people. Ask them how many non-human identities can access production, the service accounts, API keys, CI runners, bots, and now AI agents, and you'll often get a pause, then a number that's an order of magnitude larger and far less governed. The machines have outnumbered the humans for years. AI agents are about to make that ratio worse, and they're doing it with identities that were never designed to be reasoned about, audited, or attested to a regulator.
The uncomfortable truth is that most agents don't have an identity at all. They borrow one. You cannot govern, audit, or revoke something that doesn't exist as a distinct principal.
What a non-human identity is, and why agents stress the concept
A non-human identity is any actor on your systems that isn't a person: a service account, a workload, an API client, an automation. NHIs have always been a governance stepchild. They authenticate with secrets rather than passwords plus MFA, they're created ad hoc by engineers under deadline, and they tend to accumulate broad standing permissions because rotating or scoping them is annoying and nobody owns the cleanup.
AI agents are a new and especially demanding kind of NHI. A traditional service account does one narrow, predictable thing. A cron job exports a file every night. An agent is open-ended. It decides at runtime which of many tools to call, in which order, based on inputs that may be adversarial. So an agent combines the worst properties of the NHI problem (secret-based auth, a tendency toward over-permission, poor lifecycle hygiene) with a new one: non-determinism. You can't predict exactly what it will do, which means the identity it acts under, and the permissions attached to that identity, carry far more weight than they ever did for a scheduled job.
When agents are deployed quickly, the default is to give them a shared service account or a pre-existing key. That single shortcut undermines every downstream control your GRC program depends on.
Why borrowed identity breaks everything
You can't attribute actions. If five agents and two scripts all authenticate
as svc-automation, your audit log shows a blur. When something deletes a
record it shouldn't have, "svc-automation did it" is the answer, and it's
useless. You can't tell which agent, prompted by what, took the action.
You can't scope permissions per agent. A support agent and a finance agent have very different needs, but if they share an account they share its permissions, necessarily the union of everything any consumer of that account requires. The finance agent inherits the support agent's reach and the reverse. Least privilege is impossible when the privilege is pooled.
You can't revoke surgically. Discover one agent is misbehaving, and your only lever is to disable the shared account, which breaks every other consumer. So nobody pulls the lever, and the misbehaving agent keeps running. Shared identity converts a small incident into an all-or-nothing decision, usually made at the worst possible moment.
You can't apply differentiated policy. Maybe agents should never write to production, but a specific deployment agent should, under approval. If identity is shared, "this agent, under this policy" isn't expressible. Policy has nothing to attach to.
Lifecycle and ownership go dark. Who owns this agent? When was its credential last rotated? Is it still in use? With borrowed identity, an agent isn't a managed object at all, so these questions have no answer, and orphaned access lingers indefinitely. Your auditors will notice.
Why doing it right is genuinely hard
Giving every agent its own identity sounds obvious. In practice, three frictions push the other way.
First, provisioning at the speed of agents. Humans are onboarded over days. Agents may be spun up, scaled, and retired in minutes. The identity system has to mint, scope, and revoke principals at machine speed, which most IAM tooling, built around human lifecycles, handles poorly.
Second, scope is contextual. An agent's appropriate permissions depend on the task it's doing right now, not on its standing role. A fixed permission set is either too broad most of the time or too narrow for the occasional legitimate action. Identity alone isn't enough. It has to pair with policy that can reason about context.
Third, credentials still have to live somewhere. A distinct identity needs distinct credentials, and if those credentials are long-lived secrets sitting in the agent's environment, you've recreated the original problem with extra steps. Real NHI hygiene means short-lived, brokered credentials, not a per-agent vault of standing keys.
What good looks like
An auditor or security architect should be able to point at any agent and get clean answers. The properties that make that possible:
- Each agent is a distinct principal. It has its own identity, separate from every human and every other agent. It can be named, owned, described, and reasoned about in isolation.
- It has its own policy lane. Rules apply to this agent: what it may touch, what's off-limits, what requires approval, what its budget is. A finance agent and a support agent can be governed differently because each has somewhere for policy to attach.
- Its credentials are short-lived and scoped. The agent doesn't hold a standing key. It receives narrow, time-bound authority for a specific action, brokered at call time, so there's no durable secret to steal or to forget to rotate.
- It has its own audit trail. Every action the agent takes, and every action that was blocked, is attributed to that agent specifically. When you read the log, you know exactly which principal did what, and you can reconstruct why.
- It can be revoked surgically. Kill one agent's access without touching anything else. The blast radius of a single compromised or misbehaving agent is exactly that agent.
- It has a lifecycle. Created with an owner, scoped at creation, rotated automatically because credentials are short-lived by design, and decommissioned cleanly when retired. No orphans.
The unifying idea: an agent is a first-class principal, on equal footing with a human user in your identity model. Authenticated as itself, authorized for itself, audited as itself. Anything less and you're governing a ghost.
Where the principal model lives in practice
This is a core design commitment in how Cytra approaches agent governance. Agents and other non-human identities are treated as first-class principals, each with its own policy lane and its own audit trail, rather than as anonymous traffic riding a shared service account. In the call path, an agent's identity is resolved per tenant and per tool, deterministic policy is applied to that principal (production-write blocks, IP allowlists, budget ceilings, approval gates, PII redaction, with an operator kill-switch), and the action is recorded, allowed or denied, in a per-tenant, hash-chained audit log attributed to that specific agent. Credentials are brokered as short-lived, tool-scoped tokens, so the identity is real without a standing secret in the agent's hands. The result is that compliance becomes a record of how each agent ran, agent by agent. For compliance officers and security architects, stated plainly: the Cytra gateway and these capabilities are in private beta, not GA, and the platform is built to be aligned and audit-ready, not certified. SOC 2 Type II and a HIPAA BAA are in process, not granted.
Takeaway: an NHI checklist for agents
Before an agent acts on anything that matters, confirm each of these:
- Distinct principal. The agent has its own identity, not a shared service account.
- Own policy lane. Rules apply to this agent specifically, including what requires approval.
- Short-lived, scoped credentials. No standing keys in the agent's environment.
- Dedicated audit trail. Every action and denial is attributed to this agent by name.
- Surgical revocation. You can cut one agent's access without breaking others.
- Owned lifecycle. The agent has an owner, automatic credential rotation, and a clean decommission path.
The machines already outnumber the people on your systems, and the agentic wave is widening the gap fast. Identity is the foundation every other control stands on. Treat your agents as the first-class principals they've already become, or accept that, when something goes wrong, your most truthful answer to the board will be "a shared account did it, and we're not sure which one."