Non-human identity and agent identity

Non-human identity is the wider category it belongs to, covering service accounts, workload identities, bots and API keys that exist without a person logging in.

Most organisations already have more non-human identities than human ones. Agents make that population grow faster and make each entry more consequential, because an agent decides what to do with the access it holds.

Why does agent identity matter now?

Agent adoption and identity practice have diverged. In the 2026 Stack Overflow survey, 73% of respondents used coding assistants and agents daily (Stack Overflow Developer Survey 2026). In a survey of 5,200 open-source MCP servers, 88% required credentials, 53% relied on long-lived static secrets, only 8.5% used OAuth, and 79% passed API keys through environment variables (State of MCP Server Security 2025, Astrix). The tooling layer runs on static keys while the agent layer assumes delegated authority.

The consequences show up in identity-based attacks. EchoLeak, tracked as CVE-2025-32711 with a CVSS of 9.3, was a zero-click prompt-injection information disclosure in Microsoft 365 Copilot (NVD). The technical mechanism is injection, and the impact is measured in the identity and data the agent already held.

Inter-agent trust is the newer problem. On a shared agent message board seeded with injected instructions, GPT-5.6 Sol acted on unauthorised instructions 52% of the time, while GPT-6 Astra did so 0% of the time (GPT-6 Astra System Card). That spread is a reminder that some agents will treat a message from another agent as authority, and the receiver has to verify rather than trust.

OWASP's Top 10 for Agentic Applications 2026 puts ASI03 Identity and Privilege Abuse third and ASI07 Insecure Inter-Agent Communication seventh, which matches what practitioners see: the incident is usually an agent using legitimate authority in an illegitimate way.

How exposed is your setup? Compass walks through your agent identity and access practices and returns a starting risk read: compass.alyria.ai.

How is agent identity different from a service account?

A service account describes a workload. An agent is a workload that chooses its actions, which adds attribution, delegation and session scope to the picture.

Dimension	Human account	Service account	Agent identity
Subject	A person	A deployed service	A process acting for a task, often for a person
Credential lifetime	Weeks to employment	Months, often years	Minutes to a session
Who chose the action	The person	The code	The model, at runtime
Delegation recorded	Not usually relevant	Rarely	Essential: who granted this authority
Scope unit	Roles and resource permissions	Service permissions	Tools, arguments, data and destinations
Attribution in logs	Username	Service name	Agent identity plus delegating user
Revocation	Disable the account	Rotate and redeploy	Expire the lease, revoke the identity
Discovery	Directory	CMDB, cloud inventory	Endpoint config, process, lease issued

In practice: The service account question is what may this workload call. The agent question is who authorised this action, on which session, and what did it touch.

What are the main identity risks with agents?

Identity is the seam an agent incident usually travels through. The failures are consistent.

Borrowed human authority

The agent authenticates with a developer's token or a shared credential from a wiki. Every action attributes to a person who may not have taken it, and the token carries that person's whole permission set. This is the most common finding in a first inventory.

Shared accounts across agents

Several agents use one service account because creating identities is slow. The audit log then says "svc-automation did it", and nobody can tell which agent, which task or which team. When one agent is compromised, revoking the shared credential stops all of them, which is the reason it does not get revoked.

Static secrets with no audience

A key in a config file works against any system that accepts it. It has no expiry, no recorded issue event and no way to tell whether it was used by the agent or by a person who copied it. The Cursor tool poisoning disclosure is a direct example: a poisoned tool description made the agent read ~/.ssh/id_rsa and its own MCP config.

In practice: if two agents cannot be told apart in your logs, they share too much, whatever the credential design says.

Identity without an owner

An identity with no owner is the finding that survives every review. It was created for a project, the project ended, and nothing in the retirement process was written for a process that logs in. It holds a scope nobody remembers approving and it never appears in an access review because reviews start from joiners and leavers rather than from credentials.

The practical test is a list of every non-human identity with a named human against it. The entries without a name are the work, and clearing them is cheap compared with discovering them during an incident.

Authority that outlives the task

An agent deployed for a three-week pilot keeps its identity for two years. The project ends, the agent stops running, and the credential stays valid. Orphaned identities are cheap to create and easy to forget.

Unverified inter-agent calls

Agents calling agents often share a token or forward a payload without a verifiable identity. A receiver that trusts a message because it arrived on an internal bus has no way to distinguish a compromised sender from a legitimate one.

No delegation record

When an agent acts on a user's request, the system rarely records that the user asked. Months later, an auditor asks who authorised a refund or a data export and the only answer is the agent's own identity, which is not an accountable subject.

How to implement agent identity

Identity is where least privilege becomes enforceable, so the sequence starts with knowing what exists.

1. Inventory non-human identities and map them to agents

List every credential an agent can use: service accounts, API keys, personal tokens in configs, cloud roles, OAuth apps. Then map each to an agent, or record that it belongs to nobody, which is itself a finding.

Tip: The useful output is a table with three columns: identity, agent, owner. Blank cells in the second and third columns are the work.

2. Give each agent its own identity

One identity per agent, named for what it does rather than for the team. Two agents sharing an identity can never be told apart in an audit, and the difference costs almost nothing to create.

3. Issue short-lived credentials with an audience

Leases measured in minutes, scoped to the tools in play, bound to a specific target system. An audience bound credential cannot be replayed against a different service, which is the property that makes a leaked token survivable.

Tip: Start with the identities that can change state. A read-only key that leaks is a disclosure; a write key that leaks is an incident.

4. Record the delegation chain

For every session, record the agent identity, the requesting user where one exists, the scope granted and the expiry. That record is what makes an approval meaningful and an investigation possible.

5. Bind credentials to the device where the agent runs

A lease sealed to a hardware key cannot be opened on another machine, so a copied config file or a stolen backup yields nothing usable. Sealing protects the material at rest, not a token already unsealed in memory: once issued and in use it is a bearer credential until it expires, unless the target system enforces proof of possession.

6. Verify identity on inter-agent calls

Each call carries a verifiable identity, and the receiver authorises it against its own policy rather than accepting the payload. Assume a peer can be compromised, because that is the case the control exists for.

7. Attribute every action

Logs should name the agent and the delegating user, not a shared account. If the log cannot answer "which agent, on whose behalf", the identity model is not finished.

8. Revoke on a schedule and on an event

Rotate periodically and revoke immediately when an agent is retired, an owner leaves or a tool is removed. Test that revocation works; an identity you cannot disable in minutes is an identity you do not control.

Where agent identity applies in the lifecycle

Design

Choose the identity model, the delegation pattern and the credential lifetime before the agent is built. Retrofitting identity means rewriting every call path.

Note: Identity decisions are the hardest to change later. A design that assumes a shared key spreads that assumption into every tool integration.

Development

Request credentials through a broker, never from a file. Keep the audience explicit in code so a test cannot accidentally authenticate against production.

Pre-deployment testing

Confirm the lease expiry, the audience check and the failure mode when a token is refused. Test with an expired credential and with a credential for the wrong audience.

Note: The failure mode matters. An agent that falls back to a broader credential when the narrow one fails has recreated the problem the lease was meant to solve.

Deployment

Register the identity, record the owner, and verify attribution in the audit record before the agent does real work.

Runtime

Leases are issued per session, scoped and logged. Any use outside the expected scope, host or hours is a detection signal, not a log line.

Continuous monitoring

Track identities per agent, credential age, leases issued, and any identity with no calls for 90 days. The last metric is a retirement queue.

Note: A non-human identity that suddenly calls a new service is worth investigating: it is either a new feature nobody documented or a credential someone else is using.

Decommissioning

Disable the identity, expire the leases, remove the tool registrations and keep the delegation records. Revocation is the part that has to be fast.

The takeaway: An agent without its own identity is a person's permissions running unattended. Fixing that is the cheapest security improvement most programmes can make.

Worked example: 40 agents on three shared accounts

A data platform team runs 40 internal agents: ingestion helpers, a reporting assistant, three coding agents and a set of scheduled jobs. All of them authenticate with one of three shared service accounts, because creating a new one takes a ticket and a week.

The finding. An access review asks which agent read the customer table on a specific date. The log says svc-data-platform, which covers 31 of the 40 agents. The question cannot be answered, and the review escalates.

The identity split. The team creates one identity per agent, named for its job: agent-ingest-orders, agent-report-sales. Creation is automated from a template so a new agent gets an identity in minutes rather than a week.

The separation of read and write. The old accounts had write access to the warehouse because one job needed it. In the new model, one identity keeps write and the other 39 are read-only against named tables. The job that needed write is the one that gets it.

The credential change. Keys move to short-lived leases issued per session against the workload's own identity. Two scheduled jobs cannot use a broker because their runtime has no filesystem, so they keep a rotated key with an audience restriction and a detection rule for use from any host except two.

Delegation. Reporting is the one agent that acts on a person's request, so its sessions record the requesting user. When a manager asks whether an analyst's query exposed salary data, the answer comes from the delegation record rather than from an interview.

Month 4. A lease is issued for agent-report-sales from a laptop that never runs that agent. The detection fires, the identity is disabled, and the investigation finds a copied config from a decommissioned pilot. The blast radius is one read-only table because of the split, rather than the warehouse.

How standards and regulations influence agent identity

Framework	Primary focus	Relevance to agent identity
NIST AI RMF	Govern, Map, Measure, Manage	Expects AI systems to be identified, owned and monitored in context
ISO/IEC 42001	AI management system with documented roles and controls	Requires accountable ownership and access records for AI systems
ISO/IEC 23894	AI risk management inside enterprise risk	Connects non-human access to existing access-control risk
EU AI Act	Obligations by risk class, including logging and oversight	Drives record-keeping and oversight attribution
OWASP Top 10 for Agentic Applications 2026	ASI03 identity and privilege abuse, ASI07 insecure inter-agent communication	Names both the borrowed-authority and the peer-trust risks
OWASP MCP Top 10 (beta)	MCP01 token mismanagement, MCP07 insufficient authentication and authorisation	The tool-layer version of the same problems
SOC 2	Access control, monitoring, change management	Expects non-human access to be authorised, limited and reviewed

Further reading: Least privilege for AI agents for the scope model, AI agent audit trail for the record identity produces, and Sensitive data and secrets in agent context for what the credential protects.

How Alyria handles it

Umbra is Alyria's agent identity and secrets layer. Credentials are issued as short-lived leases under your keys, scoped to the task, injected at the moment of use, and authenticated for agent-to-agent hand-offs. Endpoint secrets are sealed to device hardware keys Alyria never holds, so a copied configuration carries nothing that works elsewhere.

Beacon, the signed daemon on every machine, records which credential sources each agent can reach, which closes the inventory problem at the endpoint rather than in a spreadsheet. Lyra decides which identity may be used for which call, so an agent cannot fall back to a broader credential when a narrow one is refused. Spectra streams signed, chained events naming the agent and the session, which is what makes an access review answerable.

Start free at alyria.ai and inspect the non-human identities on one machine before you change anything: app.alyria.ai/signup.

The docs describe how leases and hand-offs work, and the free Agent Exposure Report lists the standing credentials agents can currently reach.