Why AI agents need their own auth

Most teams building AI products reach for what they already have. They already have user auth. Agents need to make API calls. So they issue the agent a user session token, or a long-lived API key, and move on. It works until it doesn't.

The problem with user sessions

User sessions were designed for humans sitting in front of browsers. They expire when the browser closes, require interaction to refresh, and carry full user permissions. When you hand a session token to an agent, you're giving it everything that user can do — not what the agent actually needs for its job.

A few things go wrong quickly:

• The agent runs overnight. The session expires at 2am. The job silently fails and nobody notices until morning.
• The agent hits a rate limit that was meant for users. A human refreshes once every few seconds; an agent in a loop hits the same endpoint 200 times a minute.
• The session leaks. It's in a log file, a crash dump, a CI variable. A user session token gives whoever finds it the keys to the user's entire account.
• You can't audit what the agent did. The logs show user@company.com took 847 actions. You don't know which ones were the human and which were the agent.

API keys don't solve it either

The next move is usually a service account with an API key. Static, doesn't expire, scoped to a service. This fixes the expiry problem but creates a different one: you now have a credential with no owner, no scope enforcement, and no way to tie its actions back to the user who authorized them.

One API key per agent means every agent can do everything that API key can do. There's no narrowing, no delegation, no way to revoke one agent without revoking all of them.

Real agent systems spawn sub-agents. A user authorizes a coding assistant. The coding assistant spins up a search agent, a PR agent, and a code review agent. With API keys, all three get the same access. When the PR agent opens something it shouldn't, you can't isolate it without breaking everything else.

What agent auth actually needs

Four things matter for agent identity. None of them are complicated individually, but they need to work together.

1. Identity that's separate from users

Each agent should have its own ID, its own credential, and its own audit trail. That identity should be tied to the user who authorized it — not be the user. An agent acting on behalf of Alice is not Alice.

2. Scoped permissions

The agent should only be able to do what it was specifically authorized to do. Read-only access to repositories, not write. One organization, not all of them. Permissions should be explicit and verifiable at the time of each API call.

3. Delegation chains

When a parent agent spawns children, those children should inherit a subset of the parent's permissions — never more. The chain should be revocable: cancel the parent and all children stop working too. This is how you handle an agent that goes rogue without touching user credentials.

4. Audit trail

Every action an agent takes should be logged with the full chain of who authorized it. Not just “agent-123 called GET /repos” but “agent-123 (child of agent-89, delegated by user Alice at 14:23) called GET /repos.” When something breaks, this is how you figure out what happened.

How kavachOS handles this

In kavachOS, AgentIdentity is a first-class entity, not a user with a different label. Agents have their own credentials, their own permission scopes, and a parent reference that traces back to the delegating user.

import { createKavach } from 'kavachos';

const kavach = createKavach({
  apiKey: process.env.KAVACHOS_API_KEY,
});

// User authorizes a parent agent
const agent = await kavach.agents.create({
  name: 'coding-assistant',
  permissions: ['read:repos', 'write:prs'],
  delegatedFrom: userId,
  ttl: '8h',
});

// Parent spawns a child with narrower scope
const searchAgent = await kavach.agents.delegate({
  from: agent.id,
  permissions: ['read:repos'],  // subset only
  ttl: '30m',
});

// Revoke parent — children stop working automatically
await kavach.agents.revoke(agent.id);

Every call made under searchAgent is logged with the full delegation chain. MCP tool servers can verify agent tokens using standard OAuth 2.1 — no custom middleware required.

The model works whether you're building a single agent that does one job, or a multi-agent system where orchestrators spin up hundreds of workers. The permissions narrow at each level and the audit trail is complete at every level.