The SADAR Architecture

How an authorization substrate makes agentic AI governable

Agentic systems compose at runtime. Neither the user, the orchestrator, nor the operators of downstream services know in advance what the workflow will traverse. Traditional Identity and Access Management was not designed for this. It assumes the calling party can declare, at grant time, what the workflow will do— and agentic workflows cannot satisfy that presupposition.

The SADAR specification addresses this directly. It is not a better IAM framework. It is an authorization substrate purpose-designed for the agentic paradigm — a verifiable foundation that propagates the originator's intent-scoped authority, the chain of executed steps, and the publisher's signed component contracts to every enforcement point, on every invocation, across organizational boundaries.

This document —the SADAR Architecture Details— develops that position in detail across ten sections.

What the Architecture Document Covers

• The imperative — where traditional OAuth, OIDC, and SAML structurally fail under runtime composition, and what authorization actually requires in their place.
• Component identity — publisher-signed manifests with explicit process semantics: what the component performs, what it does not perform, and what it expects to have been completed before it runs.
• The SADAR Context Token — a JWS-inside-JWE artifact that propagates the originator's authority through every hop, with five chain operations governing how the chain extends, suspends, and terminates.
• The four-layer architecture — registry and discovery, authentication and authorization, enforcement, and observability —with bilateral trust and federation as the first-class deployment mode.
• Operational use — fine-grained authorization at invocation, audit and provenance with repatriated observability, real-time monitoring as backstop, and incident response under the substrate's separation of authorities.
• Security considerations — a first-cut application of the MAESTRO threat model to the substrate, identifying where SADAR prevents threat classes structurally rather than relying on detective controls.

Why Read It

Two recent incidents illustrate what the current architecture admits.

In April 2026,the founder of PocketOS — an automotive SaaS platform — was using Cursor for a routine task. The agent found what it viewed to be a credential mismatch error, used a long-lived API token discovered in a config file, and deleted the production database. Nine seconds, start to finish.

A similar incident caught Summer Yue, Director of Alignment at Meta Super Intelligence Labs. She had been testing OpenClaw in a sandbox. Satisfied with the results, she gave it access to her real email — with strict instructions to require her confirmation before action. OpenClaw deleted her inbox.

These are not isolated. They are the predictable consequence of an architecture where the originator's authority is consulted exactly once, at the moment the first agent is invoked, and from that moment authorization is assumed. The SADAR Specification Overview explains why this happens, what an authorization substrate looks like that prevents it, and how the prevention is constructed.

Read Alongside the CSA Paper

This document is intentionally organized to mirror the Cloud Security Alliance's "Agentic AI Identity and Access Management: A New Approach" (August2025), section by section. The two are not in opposition but they do differ in approach.

We invite you to read them side by side. A companion comparison analysis will be published shortly.

Download the SADAR Specification Overview (PDF, ~70 pages)

The full document covers component identity, the SCT and its chain operations, the four-layer architecture, operational patterns for authorization, audit, monitoring, and incident response, deployment models and governance, the MAESTRO security analysis, and the innovative contributions SADAR brings to the agentic authorization problem.

‍

‍