AI agent identity

The problem

In most deployments an agent borrows something: a user's token, an API key, a service account created for an integration years earlier. Attribution collapses immediately — the audit trail shows a person or a service, not the agent that decided.

Revocation collapses with it. Stopping the agent means disabling the credential it borrowed, which also stops the human or the integration that legitimately depends on it.

Why runtime matters

An agent's appropriate scope depends on what it is doing right now, not on what it was provisioned for. Identity that is only checked at session start cannot express that.

Verifying the principal at each action makes scope, lifetime and revocation meaningful — and makes evidence attributable to the actor that actually decided.

How Skipr fits

SecureConnect establishes identity for people, devices, applications and workloads. AgentConnect extends the same treatment to AI agents, with their own identity, their own scope and their own lifetime on the same runtime path.

Questions

Can an agent inherit a user's permissions?

It can be delegated a narrower scope derived from a user's authority, but it should hold its own identity so the action is attributed to the agent and can be revoked without affecting the user.

What happens when an agent spawns another agent?

The second agent is a separate principal with its own identity and scope; the chain is recorded in evidence rather than flattened into the originator.

How is an agent identity revoked?

Independently, at runtime. Subsequent actions fail the Identity stage without touching the human operator or the underlying service accounts.

Is this the same as machine identity?

It is the same discipline applied to a different principal. Machine identity covers workloads and devices; agent identity covers autonomous decision-makers.