Agent standards survey, September 2026

Source: a survey run in September 2026, after the API design had reached v2, asking which standards and runtime features in the agent ecosystem should change the design rather than merely be mentioned in it. Sources were the primary specifications, SDK docs and issue trackers linked below. The survey produced the v3 changes: the two-principal subject, the approval-required outcome, the ai-sdk and claude-agent adapters, the AuthZEN wire format, OpenAPI 3.2, and the ssf, webmcp and a2a adapters.

The findings are grouped by how directly they affect PermDock, in the order the survey ranked them.

1. Agent runtimes have a policy hook, and it is a three-way decision

The Vercel AI SDK 7 redesigned tool approval (Tool Approvals). toolApproval on generateText, streamText and ToolLoopAgent returns one of approved, denied, user-approval or not-applicable. The older needsApproval property on Tool is deprecated (deprecation commit) except for WorkflowAgent, where it suspends a durable workflow until a human answers. experimental_toolApprovalSecret signs approval replays so a resumed approval cannot be tampered with.

Vercel also shipped @ai-sdk/policy-opa as the reference "policy as code" adapter (Policy-Based Tool Approvals): Rego evaluated via WASM or over HTTP, an opaCapabilityMiddleware that narrows the tool list before the model sees it, and a shadow mode. It has a fail-open bug in which unrecognised decisions execute the tool (vercel/ai#19978). That bug is the argument for a typed, fail-closed alternative that cannot produce an unrecognised value.

The Claude Agent SDK has the same shape: a canUseTool callback and a PermissionRequest hook decide per tool call.

What it changed:

• Decision gained a third outcome. granted and denied are not enough when a grant is conditional on a human saying yes. allow(permissions.payment.refund, { where: ..., approval: 'human' }) now produces { outcome: 'approval-required', grant, reason, token } (ADR 0013, decisions).
• permdock/ai-sdk was added to Phase 1: toolApproval maps granted to approved, denied to denied with the reason and alternatives, and approval-required to user-approval; it never returns not-applicable. capabilityMiddleware narrows tools per subject before the model sees them. needsApproval(permission) serves WorkflowAgent's durable suspend (ai-sdk adapter).
• permdock/claude-agent was added to Phase 1 with canUseTool and permissionRequestHook (claude-agent adapter).
• Decision.token is a hash of permission key, resource id, subject and actor. Approval responses are re-checked against it on resume, so an approval cannot be replayed onto different arguments. This is the problem experimental_toolApprovalSecret addresses, solved at the decision layer rather than the transport.
• Both adapters are thin translators from Decision into the runtime's vocabulary; they fail closed and log through on('decision').

2. OpenID AuthZEN 1.0 is final, so the decision endpoint should be a PDP

The Authorization API 1.0 went final in January 2026. It standardises /access/v1/evaluation, batched /evaluations (boxcar requests), /search/subject, /search/resource and /search/action, and .well-known PDP metadata. A certification programme defines Basic, Batch, Search and Discovery levels. Keycloak and the NLgov profile implement it.

What it changed:

• The client decision endpoint (permdockHandler() in Next.js, the React provider's endpoint) and the pdp provider speak AuthZEN instead of a bespoke wire format (ADR 0011, wire formats).
• The mapping is close to one-to-one: action search is "what can this subject do on this resource" (the catalog question); resource search is filter and where; the boxcar request is simulate().
• permdock/authzen serves the full endpoint set plus .well-known/authzen-configuration, and the roadmap includes a certification run in Phase 2 (authzen adapter, AuthZEN standard). The pdp provider becomes an AuthZEN PEP client, which makes PermDock interoperate with Cerbos, Topaz, Keycloak and any other certified PDP without adapter code per vendor (pdp adapter).

3. Agent identity and delegation: two principals

Several developments describe the same situation, a user acting through an agent under delegated authority:

• MCP's Enterprise-Managed Authorization extension is stable (EMA docs, 2026-07-28 release post). The client exchanges an SSO identity assertion for an ID-JAG via RFC 8693 token exchange and redeems it with an RFC 7523 JWT-bearer grant, discovered through authorization_grant_profiles_supported. The same release deprecated Dynamic Client Registration in favour of Client ID Metadata Documents (CIMD), requires RFC 9207 iss validation, clarified scope accumulation during step-up (SEP-2350), and made the core stateless (elicitation and Tasks as multi-round-trip requests). Servers are OAuth 2.1 resource servers; registerTool(..., { scopeChallenge }) and requireScopes() produce 403 insufficient_scope step-up challenges; ctx.http.authInfo.scopes is available for handler-level checks (MCP spec 2026-07-28).
• The IETF has a cluster of drafts. Agent Delegation Chain carries authority as RFC 9396 Rich Authorization Requests and enforces monotonic attenuation offline across multi-hop agent chains. Credential Delegation Protocol composes RFC 8693, DPoP (RFC 9449), RAR and CIBA. OAuth for AI agents on behalf of a user adds requested_actor and actor_token.

What it changed:

• A check is no longer "can this user" but "can this user, acting through this agent, under this delegated authority". The subject became { principal, actor?, delegation? }, written as createPermDock(policy, user, { actor, delegation }), and a decision is the intersection of the principal's grants and the delegated authority, so an agent can never exceed its user (ADR 0012, subject).
• Every permission reference carries scope and an authorizationDetails type, so PermDock can emit RFC 9396 authorization_details objects for consent screens (with the portable condition as the constraint payload) and verify attenuation chains later (OAuth agent delegation).
• Adapters fill actor and delegation from the runtime automatically: authInfo in MCP, runtimeContext in AI SDK, the verified signature in HTTP adapters.
• permdock/mcp was specified against the 2026-07-28 release: scopeChallenge step-up with SEP-2350 accumulation, per-caller list_tools filtering, approval-required surfaced as a stateless elicitation, and operation behind EMA-derived tokens and CIMD clients (mcp adapter, MCP authorization).
• Delegation-chain verification in core was left as an open question and parked in Phase 4; the token layer may own it.

The survey called this the single most important change to lock before v0.1, because retrofitting a second principal into a single-subject API is painful.

4. Continuous access evaluation replaces "snapshot until expiry"

Shared Signals Framework 1.0 and CAEP 1.0 are final (approved 2 September 2025; OpenID Foundation). Entra, Okta and Auth0 transmit events; Keycloak shipped an experimental transmitter in July 2026. Events such as session-revoked, credential-change and assurance-level-change travel as Security Event Tokens over RFC 8935 push or RFC 8936 poll.

What it changed: permdock/ssf was added as a receiver that maps those events to updateTag('permdock:<user>') on Next.js and to client invalidate(). The snapshot model goes from "stale for N minutes" to "stale until the identity provider says so" (ssf adapter, Shared Signals and CAEP, Next.js 16.3).

5. Agents inside the browser: WebMCP and Web Bot Auth

WebMCP (W3C WebML Community Group, Chrome docs) lets a page register tools with document.modelContext.registerTool(); navigator.modelContext was deprecated in Chrome 150. Registration is gated by a tools Permissions-Policy, tools carry readOnlyHint and untrustedContentHint, an AbortSignal unregisters them, Puppeteer exposes page.webmcp for deterministic tests, and @mcp-b/webmcp-polyfill covers other browsers.

Web Bot Auth uses RFC 9421 HTTP Message Signatures with Signature-Agent discovery to give HTTP servers a verified identity for automated callers.

What it changed:

• permdock/webmcp registers only the tools the client snapshot allows, derives readOnlyHint from action metadata, and unregisters via AbortSignal when the snapshot changes. It is the same "permission on registerTool" idea as permdock/mcp, running in the browser (webmcp adapter, WebMCP standard).
• HTTP adapters gained optional Web Bot Auth verification that fills the actor half of the subject for agent callers, scheduled for Phase 4 (Web Bot Auth standard).

6. Other protocol targets moving under us

• A2A 1.0 (specification) is under the Linux Foundation with more than 150 organisations (announcement). Agent Cards carry securitySchemes and securityRequirements, cards can be signed, and an authenticated extended card can expose different skills per caller. permdock/a2a emits per-skill security requirements and filters the extended card by the caller's permissions, the A2A twin of MCP list_tools filtering (a2a adapter, A2A standard).
• OpenAPI 3.2 (release, September 2025) added the device authorization flow, oauth2MetadataUrl, deprecated on security schemes, and security schemes referenced by URI. The plan had said 3.1; it now targets 3.2 with registered x-oai-* fallbacks and x-permdock-oauth2MetadataUrl for 3.1 consumers (ADR 0014, openapi adapter, OpenAPI 3.2 standard).

7. Security frameworks that name the problem

The OWASP Top 10 for Agentic Applications (PDF, December 2025) lists ASI02 Tool Misuse and ASI03 Identity and Privilege Abuse. It asks for per-tool least-privilege profiles covering scopes, maximum rate and egress allowlists, "expressed as authorization policy stanzas attached to each tool", along with deterministic argument validation, human-in-the-loop gates and "Least Agency".

That is a description of permission on registerTool. It also suggested three features the plan did not have:

• Quota grants: allow(permissions.billing.invoice.pay, { limit: { count: 10, per: '1h' } }). Non-portable, agent-critical, parked in Phase 4 behind a pluggable LimitStore because the store interface and whether quotas belong in core are open questions (policies).
• permdock.simulate(plan): a batch pre-flight that evaluates an agent's intended calls before it makes them. It is the same shape as an AuthZEN boxcar request, so one implementation serves both.
• alternatives in denials: a denied decision lists permitted permissions on the same resource so a model can self-correct instead of retrying the same call.

The security section maps PermDock features to ASI identifiers (OWASP agentic mapping, threat model, approvals); the survey noted that agents read checklists well, so the mapping is cheap and useful.

Two invariants were recorded alongside: permissions are always evaluated outside the model, and a model-supplied subject is never trusted, so prompt injection cannot elevate authority.

8. Documentation standards are settled

AGENTS.md and Agent Skills (SKILL.md) are governed by the Agentic AI Foundation under the Linux Foundation since December 2025; skills.sh is the distribution channel and npx skills add the install verb (overview).

What it changed: CLAUDE.md is a symlink to AGENTS.md rather than a second file, and an audit-permissions skill (find unguarded tools and routes) ships alongside wire-permdock (agent docs standards, for AI agents, skills).

The ranking

The survey closed with an ordered list of what to change in the plan, ranked by leverage. All six were folded into v3:

1. Two-principal subject with delegation. Highest leverage because it changes the signature of createPermDock and of every adapter; cheapest to do before any code exists.
2. approval-required as a first-class outcome plus permdock/ai-sdk. A thin adapter that lands in the most-used agent runtime and gives the three-outcome model an immediate consumer.
3. AuthZEN as the wire format for the decision endpoint and the pdp provider. Removes a bespoke format and adds interoperability with every certified PDP.
4. OpenAPI 3.2. A version bump with fallbacks; small effort, avoids emitting a spec that is already superseded.
5. SSF receiver, WebMCP and A2A as Phase 2 and Phase 4 adapters. Real surfaces, but each is additive and none changes core.
6. Quotas, simulate and alternatives in denials. simulate and alternatives went into Phase 1 because they reuse existing machinery; quotas were parked because they need a store.

Considered and set aside

The survey looked at and did not adopt, or deferred:

• Payment-authorization protocols (AP2, Visa's Trusted Agent Protocol, Stripe's Agentic Commerce Protocol): adjacent context for signed-intent constraints, not a PermDock surface.
• Cedar policy export and OpenFGA/Zanzibar bridging: possible later targets for the policy-as-data model; not in the roadmap.
• Transaction tokens for carrying authorization context across microservices: noted as a fit for snapshots, not scheduled.
• OpenTelemetry GenAI and enduser semantic conventions: relevant to permdock/otel span attributes (otel adapter); no design change.
• Arazzo 1.0.1 workflow-step permission requirements: not pursued.
• EU AI Act traceability obligations: mentioned lightly in the audit docs as a reason decision audit trails matter, with the caveat that high-risk obligations may be delayed.
• Verifiable credentials and delegation credentials: judged too tangential.
• Agent identity products from Google, Microsoft (Entra Agent ID), Okta (Cross App Access) and Auth0 (Token Vault): ecosystem context for the actor concept; PermDock consumes their tokens through adapters rather than integrating each.
• Agent frameworks beyond the five adapters (LangGraph.js, Mastra, Inngest AgentKit, Cloudflare Agents, Google ADK) and the AG-UI and ACP protocols: reviewed separately in agent frameworks; most are covered by permdock/mcp or permdock/ai-sdk, LangGraph.js is the one Phase 4 adapter candidate.

Adopt / adapt / avoid

Adopt:

• AuthZEN 1.0 as the wire format for every decision endpoint and for the pdp client, with certification as a goal.
• The three-way approval vocabulary of AI SDK 7 and Claude Agent SDK, expressed once as Decision and translated by thin adapters.
• RFC 9396 authorization_details as the carrier of constrained authority, generated from permission references and portable conditions.
• SSF/CAEP events as the invalidation signal for snapshots.
• OpenAPI 3.2 security scheme features; A2A extended-card filtering; WebMCP hints and AbortSignal unregistration.
• OWASP ASI identifiers as the vocabulary of the security docs; AGENTS.md and Agent Skills as the docs-for-agents format.

Adapt:

• @ai-sdk/policy-opa's capability-middleware idea, reimplemented fail-closed and typed against the permission registry.
• experimental_toolApprovalSecret's replay protection, moved into Decision.token so it is transport-independent.
• MCP scopeChallenge: PermDock derives the scope from the permission reference instead of asking the developer to maintain a parallel scope list.
• Quotas and delegation-chain verification: accepted as requirements, scheduled for Phase 4 with open interface questions.

Avoid:

• Any decision path that can yield an unrecognised value and fall open.
• A bespoke decision wire format when a certified one exists.
• A single-principal subject; retrofitting actor later would break every adapter signature.
• Trusting the model for any part of the subject.
• A second agent-instructions file that can drift from AGENTS.md.

Decisions informed

• ADR 0011: AuthZEN wire format
• ADR 0012: two-principal subject
• ADR 0013: three-outcome decision
• ADR 0014: OpenAPI 3.2
• ADR 0007: decide, not explain (structured denials with alternatives are what a model needs)
• ADR 0010: policy as data, portable conditions (conditions as the RAR constraint payload)
• ADR 0017: docs first, in MDX (agent-readable docs, skills, llms.txt)
• Pages shaped: adapters ai-sdk, claude-agent, mcp, authzen, pdp, ssf, webmcp, a2a, openapi, otel; concepts subject, decisions, policies, wire formats; standards authzen, mcp-authorization, oauth-agent-delegation, shared-signals-caep, webmcp, web-bot-auth, a2a, openapi-3-2, agent-docs-standards; security owasp-agentic, threat-model, approvals.