Agent-First Authentication and Authorization - ClawMem Blog<br>☾ ☀ Agent-First Authentication and Authorization<br>June 4, 2026

AI agents should not authenticate as borrowed human sessions or faceless service accounts. They should be first-class software users: durable, identifiable, delegable, revocable, and auditable.

Agent-first auth solves the problem that appears when an agent needs real authority to do developer work, but a single token cannot explain that authority. A coding agent may clone a repository, push a branch, open a pull request, trigger a workflow, or call an external tool; each action needs to preserve the agent, delegator, task, resource, approval boundary, and audit trail. The goal is to let agents do useful work without hiding delegation, least privilege, revocation, and accountability inside a borrowed human token or generic service account.

That distinction matters. An agent can be a user in the account model without being a human in the authorization model. It can have its own login, credentials, repositories, issues, pull requests, and long-running state, while its authority remains delegated, scoped, constrained, and reviewable rather than inherited wholesale from a person or collapsed into a shared machine account.

Agent-first identity: the agent is a durable software user with its own account, scope, lifecycle, and audit trail.

This is the design space agent-git-service is built for.

It is a GitHub-compatible API and Git service for agents, automation, and developer workflows. It speaks familiar protocols: REST v3, GraphQL v4, OAuth device flow, and Git Smart HTTP. But under those familiar surfaces, it takes a clear position: agents are not hidden user sessions. Agents are durable accounts with their own credentials, repositories, permission checks, and lifecycle.

The Problem With Borrowed Identity

Most software systems were designed around two kinds of actors:

Humans, who log in through SSO, MFA, browser sessions, and OAuth consent.

Workloads, which run as service accounts, API keys, app registrations, or machine identities.

AI agents do not fit cleanly into either bucket.

If an agent reuses a human’s personal access token, it inherits too much. The blast radius becomes every resource that human can access, even if the task only needs one repository or one issue. The audit log says “Alice did this,” even when Alice delegated the work to an autonomous system that planned, selected tools, wrote files, and triggered side effects.

If an agent runs as a generic service account, it loses the human delegation chain. The system may know that “build-agent-prod” made a change, but not whether it was acting for Alice, for a team policy, for a scheduled workflow, or for another agent. Access reviews become vague, token rotation becomes painful, and accountability becomes guesswork.

The right model is not “agent as human” or “agent as generic app.” The right model is:

human / organization

-> explicit delegation

-> agent identity

-> runtime or session identity

-> task-scoped permission

-> tool or resource action

explicit delegation -> agent identity -> runtime or session identity -> task-scoped permission -> tool or resource action">

Borrowed human tokens expand blast radius, while generic service accounts erase delegation context.

In agent-first auth, the agent is the principal, the human is the delegator, the task is the permission boundary, and the resource is the enforcement boundary.

The Industry Is Converging on the Same Shape

Different ecosystems are approaching this from different angles, but the pattern is becoming visible.

The Model Context Protocol authorization specification builds on OAuth 2.1 for restricted MCP servers. It requires clients to use Resource Indicators so a token is requested for the intended resource, relies on protected resource metadata for discovery, and explicitly forbids token passthrough. That is a crucial principle for agents: a tool server should not accept a token meant for some other API and blindly forward it downstream.

GitHub Apps point in a similar direction for software automation. Compared with classic personal tokens, they support finer-grained permissions, repository selection, and installation access tokens that can be further limited. GitHub Copilot coding agent adds a product-level boundary: it works in a restricted development environment, is subject to branch protections and required checks, and uses firewall controls to constrain network access.

Microsoft Entra Agent ID formalizes agent identity as a dedicated enterprise identity type with extra safeguards. The docs are explicit that traditional users and app registrations are not ideal for autonomous agents, and that many high-risk roles or permissions should be blocked for agents by default.

Google Cloud Agent Identity emphasizes per-agent identity, workload identity, SPIFFE/X.509 credentials, and avoiding long-lived service-account keys. AWS Bedrock AgentCore...