Agent-First Authentication and Authorization

Agent-First Authentication and Authorization

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

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 Identity uses workload access tokens that can carry both the agent identity and the end-user identity, and pairs that with a token vault for external credentials.

Auth0 FGA models agents as authorization subjects in a relationship graph, which is useful when the real question is not “does this user have role admin?” but “is this agent allowed to act for this user on this object?”

Casdoor is interesting for a different reason: it is positioning itself as an AI-native IAM layer and MCP authorization server, not just a generic SSO product. Its Agent application category separates machine-to-machine agent apps from user-facing apps, with MCP and A2A types. Its MCP auth provider gives tool builders OAuth 2.1 infrastructure such as Dynamic Client Registration, PKCE, consent, JWKS validation, Resource Indicators, and metadata discovery. Its MCP authorization docs map scopes to tools, support custom tool scopes for third-party MCP servers, and combine scope checks with Casbin-based fine-grained policies over users, roles, resources, actions, relationships, and environment. Its Agents and OpenClaw story also points at runtime visibility: agent endpoints can be registered, and tool calls or agent interactions can be recorded as audit entries.

NIST’s concept paper on software and AI agent identity and authorization frames the problem around identification, authorization, auditing, non-repudiation, and prompt-injection mitigation. OWASP’s agentic security work highlights the same risk from the other side: over-privileged skills, weak identity validation, and privilege abuse become systemic problems once agents can call tools and mutate state.

None of these systems gives the entire answer alone. Together, they point to a practical architecture:

Give every agent a real identity.

Preserve the delegation chain from human or organization to agent.

Issue short-lived, audience-bound, resource-bound credentials.

Scope permissions to tasks, resources, actions, and context.

Put enforcement at every meaningful boundary.

Log enough provenance to explain why an action was allowed.

Different ecosystems are converging on the same agent-first auth shape: real agent identity, scoped credentials, policy boundaries, and auditable decisions.

What Agent-First Authentication Requires

Authentication for agents should not stop at “is this token valid?” It should establish which agent is acting, where it is running, which human or organization delegated the work, and which task or session the request belongs to.

A mature system needs several identity layers.

Agent authentication should establish the human delegator, agent identity, runtime identity, and task identity.

The human identity still matters. Users should authenticate through OIDC, SAML, OAuth, MFA, device flow, or another enterprise identity path. But the human login is not the agent’s credential. It is the source of delegation.

The agent identity should be stable. It should have a durable account, unique login or identifier, owner, status, creation metadata, and a token lifecycle. It should be discoverable, manageable, suspendable, and auditable.

The runtime identity should be provable when possible. Workload identity, mTLS, SPIFFE/X.509 SVIDs, OIDC workload tokens, or similar mechanisms can help distinguish “this agent account exists” from “this request came from an expected runtime.”

The task identity should be explicit. A token used for “fix issue 123 in repo A” should not also be valid for “delete repo B” or “read all organization secrets.” When the task expires, the credential should expire with it.

This leads to a few concrete authentication rules:

Long-lived secrets should be bootstrap credentials, not the normal operating credential.

Normal work should use short-lived session or task tokens.

Tokens should have a target audience and resource.

High-risk tokens should be sender-constrained with DPoP, mTLS, or workload-bound issuance where feasible.

Tokens should be revocable by agent, task, human owner, organization, and security policy.

Tool servers should not pass upstream tokens through to downstream systems.

What Agent-First Authorization Requires

Traditional authorization often asks:

Does this user have this role?

Agent-native authorization needs a richer question:

Can this agent, acting under this delegation, for this task,

perform this action on this resource in this context?

That means the authorization input should include:

Agent identity.

Delegating human, organization, or system policy.

Task or session identifier.

Resource, such as repository, issue, branch, secret, workflow, document, database, or external SaaS object.

Action, such as read, write, push, merge, delete, run workflow, read secret, send message, or call external API.

Context, such as time, runtime, branch name, network destination, risk score, approval state, and previous tool calls.

Agent-native authorization evaluates agent, delegation, task, resource, action, and context before returning a constrained decision.

The result should not be only allow or deny. It often needs to be:

Allow.

Deny.

Allow with narrowed scope.

Require human approval.

Require stronger authentication.

Allow read but block mutation.

Allow mutation but require review before commit, merge, release, or external side effect.

A task grant might look like this:

{

"agent": "agent:code-reviewer",

"delegator": "user:alice",

"task": "task:fix-payment-bug",

"resources": ["repo:acme/payments"],

"actions": ["read_code", "create_branch", "push_branch", "open_pr"],

"constraints": {

"branch_prefix": "agent/task-123/",

"expires_at": "2026-06-02T12:00:00Z",

"network_allowlist": ["github.com", "jira.example.com"],

"requires_approval": ["merge_pr", "read_secret", "run_workflow"]

}

}

A task grant is a bounded permission envelope, not a standing repository scope.

This is different from giving the agent a standing repo scope. The task grant names the agent, the delegator, the resource, the allowed actions, and the constraints. It lets the platform explain why the agent could do one thing and not another.

Why Git Is a Hard and Useful Test Case

Software agents are a demanding environment for auth design because their actions are real.

They do not just read documents. They clone repositories, inspect history, write files, advance refs, open pull requests, trigger workflows, post comments, manage issues, and sometimes touch secrets or deployment paths. A weak auth model is not an abstract risk here. It can become an unauthorized push, a leaked token, a bypassed branch protection, a forged audit trail, or a confused-deputy workflow run.

At the same time, developer tooling is deeply standardized. Agents need to work with existing Git clients, gh, REST APIs, GraphQL APIs, credential helpers, and CI/CD workflows. A theoretically pure agent protocol is not enough if every existing client must be rewritten.

This is why agent-git-service is intentionally GitHub-compatible while still making agents first-class accounts.

How agent-git-service Implements the Model

agent-git-service starts from a simple rule: one a

[truncated for AI cost control]