← Back to Writing

The Identity Layer for Agents

As agentic AI becomes increasingly autonomous, the infrastructure underpinning them is due for a serious re-evaluation. In traditional software, we take identity and authentication for granted. Users log in, services run with scoped API tokens, and infrastructure is secured through layered, well-understood models of access and trust.

Agents break this paradigm. They are ephemeral, compositional, capable of long-running tasks, multi-user delegation, and increasingly act as non-human actors with real business authority. Yet today, most frameworks give these agents no first-class identity. They operate on borrowed credentials, unverified contexts, and unscoped permissions.

This post explores how we’re addressing agent identity at MarutAI, why we treat it as a systems-level primitive, and how it enables production-grade autonomy without compromising on control, safety, or auditability.

From Output to Action

Traditional LLM interactions are single-turn, user-scoped, and isolated. Agentic systems invert this model:

  • Agents act across multiple steps
  • They use tools, invoke APIs, and write to systems
  • They may initiate transactions or workflows on behalf of others

As soon as agents move from text generation to execution, they cross a line that security and compliance teams care deeply about. And yet, most implementations still rely on:

  • Long-lived bearer tokens
  • Static secrets injected into the agent runtime
  • Implicit trust based on which environment the agent is running in

This is effectively the same as allowing a background process to impersonate a logged-in user or privileged service account. It’s a well-known failure pattern in enterprise security, responsible for decades of breaches, including domain-wide compromises caused by over-permissioned accounts on systems like Microsoft Exchange.

What Is Agent Identity?

At MarutAI, we define agent identity as a first-class subject in a zero-trust system. It is:

  • Cryptographically verifiable — Each agent has a unique keypair or identity certificate
  • Ephemeral and scoped — Identity is short-lived, linked to the context of execution
  • Delegatable — Agents can act on behalf of users or other agents, with provable delegation chains
  • Auditable — All actions tied to an identity are observable and traceable
  • Constrained — Identities are bound to specific capabilities and environments

This mirrors best practices from cloud-native security (e.g., SPIFFE/SPIRE, IAM roles), but adapted for the dynamic, multi-agent, multi-tenant environments AI systems require.

The Stack: Constructing Agent Identity

1. Workload Identity

Each agent spawned inside the orchestration runtime is issued a Unique ID via the identity infrastructure or mapped to a cloud-native workload identity (e.g. AWS Roles Anywhere).

This ensures:

  • No shared secrets or bearer tokens
  • Per-agent identities tied to a trusted issuance mechanism
  • Support for multi-cloud and hybrid deployments

2. DID + Verifiable Credentials

Assign each agent a DID (Decentralized Identifier) and associate it with a set of Verifiable Credentials (VCs) that include:

  • Agent purpose
  • Controller (user or service that spawned it)
  • Model version + tool profile
  • Policy tier and data access class

These VCs allow downstream services and other agents to validate the agent’s intent and trust posture without direct introspection.

3. Sender-Constrained Access Tokens

All API/tool calls made by an agent are protected or bound access tokens. These tokens:

  • Cannot be replayed or reused by another agent
  • Include Rich Authorization Requests (RAR) describing the action (“read records X-Y from system Z, TTL 5min”)
  • Are short-lived (<5min by default)

This replaces static scopes with explicit, auditable intents.

4. On-Behalf-Of Delegation via Token Exchange

When an agent is acting on behalf of a user, we leverage something similar to OAuth 2.0 Token Exchange (RFC 8693):

  • The user authenticates once
  • A short-lived, PoP-bound agent token is minted for a subset of allowed actions
  • Downstream systems see agent identity + user delegation context

This enables user-driven actions without user tokens ever being exposed to the agent.

5. Capability-Based Delegation Between Agents

For multi-agent workflows, use capability delegation tokens that:

  • Encode what Agent A allows Agent B to do
  • Include caveats (time, resource, data class)
  • Are signed by the delegator

These form verifiable proof chains that trace control and permissions through agent graphs.

6. Runtime Attestation

In high-trust environments (e.g. healthcare, finance), optionally require attestation:

  • TEE proofs (AWS Nitro, Azure SEV-SNP)
  • SLSA provenance + Sigstore to verify model/toolchain
  • RATS/EAT claims for runtime configuration integrity

This ensures the agent identity isn’t just “who issued it”, but also what code is running where.

Why This Matters

Without identity, agents cannot be:

  • Held accountable
  • Governed effectively
  • Delegated to with confidence
  • Composed into multi-agent workflows safely

This becomes especially important when:

  • Agents cross org boundaries (e.g., B2B interfaces)
  • Agents generate artifacts that must be signed (e.g., invoices, audit reports, insurance policies)
  • Regulators require a log of automated decisions (e.g., loan approvals)

As agentic AI becomes operationalized, the identity layer becomes as critical as the model or data layers.

Agent Identity Is Not a Feature, It’s Infrastructure

At MarutAI, we don't treat agent identity as a plug-in or bolt-on. It is a core part of how our orchestration and deployment systems are designed.

From the moment an agent is spawned to the moment it exits, every action, delegation, and data access is:

  • Identity-bound
  • Token-scoped
  • Policy-enforced
  • Auditable

This gives our customers the confidence to deploy agents in sensitive, regulated, and high-trust environments.

As the agent landscape evolves from pilots to production, we believe agent identity will be the backbone of safe autonomy, and the differentiator between platforms that scale and platforms that stall.

If you’re building agents that do more than chat, agents that act, start thinking about identity not as an afterthought, but as your new control plane.