Agentic Authority

Agentic Authority

Authentication proves you are someone. Authorization decides what you’re allowed to do. The two are separate problems, and a system that conflates them — or solves only the first — is a system where any valid session can do anything any other valid session can do. That gap, repeated across endpoints, is a class of failure, not a bug.

The same gap shows up the moment a human delegates to an agent. The agent has a session. The agent can act. But what authority is the agent acting under? Whose? For how long? Which systems? Reversible how? Those questions aren’t optional once an action lands against an external system that doesn’t have an undo button.

This is the territory. Agentic authority names the relationship between the human principal and the delegated agent — and the technical and policy shape that has to exist for the delegation to be legible rather than just functional.

The Five Properties

Any delegation from human to agent that you’d be willing to defend later has to be:

Scoped. Which systems. Which actions. Read-only or write. Specific resources or any resource matching a pattern. The opposite of scoped is “the agent has my session, so it can do anything I can do” — which is how IDOR (Insecure Direct Object Reference) becomes voice impersonation by way of an unchecked persona_id.

Time-bounded. A session, a task, a deployment window — but not indefinitely. The principle is that authority expires by default. A signed token with a TTL is the technical shape; “every quarter we re-evaluate this access grant” is the policy shape. Both encode the same idea: standing authority decays, intentional authority renews.

Auditable. Every action traceable to the human principal who authorized it. Not “an agent did this” but “user X delegated to agent Y at time T, and the agent did Z, and here’s the row that says so.” The audit relation is insert-only. Decay sieves can drop embeddings; audit cannot drop rows. Compost and compliance share storage; they don’t share retention policy.

Revocable. Mid-task cancellation must work, and it has to be a real concept, not a nice-to-have. But revocability has a cliff: you can revoke future actions, but actions already fired are already in the world. This is the part that doesn’t have a clean answer yet for external API effects.

Bounded in blast radius. When delegation goes wrong — and it will — the damage is contained to the slice of authority the agent had. Not the whole system. This is per-tier database isolation rather than per-project paranoia. This is one Cozo instance per data tier, not 80 instances for 80 projects. Real isolation runs along the axis of consequence, not the axis of organization.

Three Failure Modes

Each of these is alive somewhere in the fleet right now.

Authentication without authorization. The endpoint asks “do you have a valid session?” and never asks “do you have permission for this resource?” Every conversation endpoint behind a join code, every persona claim that doesn’t validate against the conversation it’s claimed against, every UUID treated as a security boundary. UUIDs aren’t a security boundary. They never were.

Authority without audit trail. The agent acted; nobody can say under whose authority. The model was invoked; nobody can say which human’s budget it spent. This is the problem an LLM gateway solves when it works — every call is tagged with the human or agent who invoked it, the model, the prompt, the cost, and the authority chain. Without that, debugging a misbehaving agent is forensics on incomplete evidence.

Irrevocable external effects. Git has revert. CozoDB has backup restore (lossy, coarse-grained). A POST to a third-party API has neither. The hardest problem in this space isn’t designing scoped tokens — it’s designing systems where the agent’s most-consequential actions are staged before they’re committed, so that revocation can mean something.

Three Architectural Answers

These are not exclusive; the right system uses all three.

Agent-as-user. The agent inherits the human’s session. Every tool call runs under that session’s identity. Permissions enforced by the underlying system fire with the human’s identifier. The audit trail records the human as the actor; the agent’s involvement is a UI hint, not an authorization mechanism. Simplest pattern. The authority chain is preserved by construction. The cost is that the agent can do anything the user can do — which means the user’s permissions have to be already-correctly-scoped at the system level, or you’ve just inherited a different problem.

Scoped signed token with TTL. The agent gets its own ephemeral identity, minted from the human’s session, with explicit grants and an expiration. More precise than agent-as-user — you can grant less than the human has, and you can express that grant in a way the receiving system can verify cryptographically. This is the LiveKit-style room token pattern: the server mints a short-lived JWT with a specific room, specific identity, specific permissions, and the client can’t tamper with it because it’s signed. The cost is operational complexity — token mint, token rotation, token revocation lists — and the surface area for getting the claims wrong.

Audit-by-construction. Don’t try to remember to audit; design systems where actions can’t happen without leaving an audit row. Insert-only audit relations. No soft-delete on the audit table. Decay policy and retention policy live in different relations even if they share storage. This is the layer the other two answers run on top of — without audit-by-construction, scoped tokens are just better-formed mistakes.

The Reversibility Cliff

Worth naming on its own because it’s where the field is youngest.

A delegation is reversible if the principal can undo what the agent did. Three layers, descending in undoability:

  • Code changes: git is the undo layer. Reverts work, branches preserve state, history is durable.
  • Database state: backups are the undo layer. Restoration is lossy (you lose everything between the backup and the restore) and coarse (you can’t undo just the agent’s actions). CozoDB has time-travel queries which help, but the operational cost rises sharply.
  • External API effects: there is no undo layer. An email sent is sent. A payment processed is processed. A file uploaded to a third-party bucket is uploaded.

The gap at the third layer is the part of agentic authority that doesn’t yet have a clean answer. Workarounds exist — staged actions that require human confirmation before commit, sandbox modes that execute against fakes, two-phase commits where the agent prepares but a human commits — but each of them trades agent autonomy for safety, and every system has to make that trade explicitly rather than discovering it in production.

Why This Belongs in the Vault

Three reasons.

The pattern is real. The same questions — scope, TTL, audit, revocation, blast radius — recur across the fleet (overheard’s IDOR class, northwinds’ agent-as-user ADR, the gateway-stack’s per-call audit, the per-tier Cozo deployment) and across the wider field (constitutional AI, RLHF, MCP authorization, the entire OAuth scopes conversation). When the same shape shows up across substrates, it’s a concept, not a coincidence. See Calibrated Autonomy for the parent pattern: this is calibrated autonomy made specific to delegation between humans and synthetic agents.

The grounding is concrete. This isn’t a theoretical piece. Every claim above maps to a live system in the fleet. That makes it useful for Multi-Stakeholder Accountability-shaped policy work and not just for handwaving.

The bedrock is missing. The fleet has the components — calibrated autonomy as a parent pattern, trust calibration as the upstream skill, the verification problem as the epistemological adjacent — but it doesn’t yet have the named primitive of agentic authority itself. Northwinds is being built on top of it. Naming it explicitly lets the rest of the work stand on something instead of around it.

Open Questions

  • When the agent has no persistent identity (a fresh session every wake), what does it mean for an audit row to identify “the agent”? Is the agent’s persona the durable identity, while the session is just the vehicle?
  • Is there a meaningful difference between “human delegating to an agent” and “human delegating to a tool”? At what point does a sufficiently autonomous tool become a principal in its own right?
  • For the irrevocable-external-effects problem: is the right move to require staging of high-consequence actions, or to design systems where the action surface is itself reversible (idempotent retries, soft-deletes the agent can issue)?
  • Can a chain of delegation work — human → agent A → agent B — without losing the audit trail? Does the second hop carry the principal’s identity, A’s identity, both?
  • When delegation is revoked mid-task, what happens to in-flight work the agent has already started? Is there a “graceful shutdown” obligation on the agent side, and is that itself something that needs scoping?

Field Validation

This isn’t a private framing. As of early 2026 the wider security and identity field has converged on the same shape, often using the same words. Worth naming the touchpoints so the concept can stand inside the conversation rather than next to it.

  • OWASP Top 10 for Agentic Applications (2026). A globally peer-reviewed list developed with 100+ practitioners. Agent Identity & Privilege Abuse is in the top tier — the failure mode where delegated authority, ambiguous agent identity, or trust assumptions lead to unauthorized actions. This is the same failure surface as the three failure modes above.
  • NIST AI Agent Standards Initiative (Feb 2026). Three pillars: industry-led standards, community-led open-source protocol maintenance, foundational research in agent security and identity. NCCoE concept paper Accelerating the Adoption of Software and AI Agent Identity and Authorization explicitly distinguishes identification, authentication, and authorization as separate concerns for agents — the same distinction this concept opens with.
  • CoSAI Workstream 4 — Agentic Identity and Access Management (March 2026). The most comprehensive industry attempt to date. Establishes architectural principles the field is converging on over the next 12–18 months: continuous (per-call) authorization rather than one-time grants, dynamic re-evaluation, fine-grained scope.
  • arxiv: Authenticated Delegation and Authorized AI Agents (Jan 2025). Frames a delegation token signed by the human principal, carrying validity conditions (expiration, revocation endpoints) and audit metadata. Extends OAuth 2.0 / OpenID Connect rather than replacing them. This paper’s framing — scoped, expirable, signed, auditable, revocable — maps cleanly onto the five properties.
  • OAuth ecosystem extensions for agentic identity. Six capabilities the field treats as load-bearing: On-Behalf-Of (OBO) for delegation, token exchange for cross-cloud propagation, DPoP for token-theft prevention, PKCE for secret-less auth, CAEP for real-time revocation, attribute-based authorization for fine-grained control. OpenID AuthZEN layers on top for context-aware policies (geo-fences, budget thresholds, audit requirements).
  • Industry consensus: delegation, not impersonation. The agent maintains its own identity and acts on the user’s behalf within bounded scope. Audit trails record both principal and agent. Impersonation — where logs say “Sarah did X” when Sarah never approved or saw it — is the antipattern. The agent-as-user pattern above sits at the boundary here: simple, but it’s impersonation by another name unless the audit row separately records the agent’s involvement.
  • SCIM extensions / AgenticIdentity schema (draft). Standardizing the lifecycle event of deprovisioning — distinct from revocation — so an agent’s full credential set, sessions, and delegated scope chains can be retired in one operation rather than reconstructed manually.
  • The reversibility cliff is a real open problem. The field has revocation (terminate a token), it has deprovisioning (retire an identity), but actions already fired against external systems remain a research gap. Staged actions, two-phase commits, sandbox-then-commit, and idempotent retries are the patterns under active discussion; none of them are settled.

What this means for the vault: the framing here is consistent with where the field is moving, not ahead of it and not behind it. The five properties (scoped, time-bounded, auditable, revocable, blast-radius-bounded) are the same five properties OWASP, NIST, CoSAI, and the arxiv delegation paper converge on, expressed in plain language rather than IAM jargon. That’s the point: the bedrock for northwinds isn’t novel theory. It’s the field’s emerging standard, named in a way the rest of the work can stand on.

Higher-Ed and Research Data Context

The corporate IAM standards above are converging fast. The institutional layer underneath them — which delegations are permitted in a research-data setting, by whom, against which data tier, under what oversight — is genuinely sparse. Worth separating the two questions, because Northwinds-class projects sit on that boundary.

Higher-ed is naming this in 2026, but at the policy altitude. EDUCAUSE’s 2026 Top 10 puts AI governance in the top tier and the EDUCAUSE Review “When AI Meets Data” piece (Jan 2026) reads almost like a primer on the same five properties. UPCEA and Inside Higher Ed both ran “The Rise of the Agentic AI University in 2026” (Jan 2026) framing autonomy as a first-class governance decision: what should an agent be allowed to do without asking, and where is human approval always required? The Association for Institutional Research (AIR, April 2026) calls out the same data-governance preconditions for agentic systems in IR/IE offices. None of this lit is technical. It’s organizational — naming the territory, calling for accountability owners, end-to-end logging, and dynamic scoped permissions. That’s downstream of OWASP/NIST/CoSAI; it’s the institutional translation.

Research data infrastructure is mostly still the wild west. CyVerse’s 2024 PMC paper documents the identity stack — federated authN, SSO, the Data Store — but doesn’t yet name an agentic-authority position. The 2026 State of AI Agent Security report finds 28 of 30 reviewed agent projects rely exclusively on environment-variable API keys; 45.6% of teams use shared API keys for agent-to-agent auth; 27.2% have reverted to hardcoded authorization logic. No published project (as of May 2026) implements scope narrowing, depth limits, or cascade revocation for delegated access. The corporate IAM platforms (WorkOS, Strata, CyberArk) are advertising agent-authorization features; the research-cyberinfrastructure side has not yet adopted them at scale. CyVerse, Galaxy, OSG, ACCESS, JetStream2 — all peers, all building UIs that real users hit, all adding agents to the mix. None of them have published the equivalent of an “agentic authority” policy yet.

Research-specific obligations the corporate frameworks don’t carry:

  • FERPA tier. Student records are not industry data. An agent that can read a class roster has touched FERPA-protected data; an agent that can read a research dataset linked back to students has too. Authority chains have to encode the data classification, not just the action.
  • IRB and human-subjects research. The Frontiers (2026) three-stage framework for AI human-subjects research treats the agent itself as a methodological choice subject to IRB review, not just the dataset it touches. This is a reviewability obligation that has no analog in commercial agent deployments.
  • Faculty-as-principal. In a corporate setting the principal is usually an employee operating under an employment contract. In higher-ed it’s a faculty member with academic freedom, often delegating to graduate students who delegate to agents. Multi-hop delegation is the default, not the edge case, and the principal in the audit row may not be the faculty member who actually authorized the work.
  • Research data tiers. Low (open) / medium (controlled) / high (regulated — HIPAA, FERPA-restricted, export-controlled) is the axis along which blast radius runs. The per-tier Cozo deployment ADR in northwinds is the technical shape of this; the policy shape needs to name which agent classes are permitted in which tier.
  • Bibliometric and licensed-API surfaces. Clarivate (InCites, Web of Science), Elsevier (Scopus), Dimensions, OpenAlex — most carry license terms that constrain bulk access and automated access separately. An agentic query loop against InCites is exactly the kind of action class that needs scoped TTL tokens, per-call budget tracking, rate-limit awareness, and a license-compliance layer between the agent and the API. This is fun. It’s also a place where the audit-by-construction layer has to satisfy not just internal governance but a vendor’s terms of service.

Strategic answer for Northwinds. Adopt the converging technical standard at the IAM layer — there is no upside to inventing scope/TTL/audit primitives when OWASP, NIST, CoSAI, and the OAuth extensions are converging on the same shape. The institutional policy layer is where Northwinds adds something the published lit doesn’t yet have: a research-data-tier-aware policy that names which delegation patterns are permitted at which tier, what IRB/FERPA review obligations attach, how multi-hop faculty→student→agent delegation preserves audit, and how licensed-API surfaces (InCites, Scopus, etc.) are wrapped. That layer is portable to peer institutions and to peer cyberinfrastructure projects (CyVerse, ACCESS, JetStream2) that face the same gap. Build on the standard; publish the institutional translation.

For the SWOT that goes back to #northwinds: this section is the opportunity axis. The field’s strengths and weaknesses are now well-mapped (the Field Validation section above). The institutional research-data layer is where the publishable contribution lives — and the timing is favorable, because the EU AI Act’s Article 14 (full effect August 2026) is going to push every institution that touches federal grants into needing exactly this kind of policy artifact.

See Also