PATTERN Cited by 2 sources

Agentic Access Control (AAC)¶

Pattern¶

Agentic Access Control (AAC) is an access-control pattern specialised for AI agents as the requesting principal. Three properties:

No long-lived credentials — agents never hold static API keys, access tokens, or passwords. Every credential is short-lived, minted per session, and self-expires. See concepts/short-lived-credential-auth.
Per-call policy enforcement before and after I/O — policy is checked against the prompt / input / tool-call before the call is made, and against the output / action after the call completes, before the result is returned to the agent.
Fine-grained temporary access — access grants are narrow (specific resource + specific operation) and time-bounded (session-scoped or shorter), not role-scoped or account-scoped.

All three compose with audit-by-default — every decision (prompt, policy check, input, tool call, output, action) is recorded as a durable event, feeding back into the audit envelope.

Canonical statement¶

From the 2025-10-28 Redpanda Governed autonomy post (Source: Redpanda 2025-10-28):

"That's why the ADP embeds Agentic Access Control (AAC), an evolution of modern access control concepts tailored to the needs of an agentic workforce. Agents never hold long-lived credentials. Every prompt, action, and output is auditable, replayable, and policy-checked before and after I/O, empowering enterprises to grant AI agents fine-grained, temporary access to sensitive data without losing oversight — a critical milestone on the path to Enterprise AI."

Why "evolution of modern access control"¶

Modern access-control substrates (ABAC, RBAC, OIDC- federated STS, workload identity) already support most of AAC's mechanical primitives — short-lived tokens, fine-grained scopes, audit hooks. What AAC adds is specialisation for the agent audience:

Principal is the agent, not the human. Traditional access-control binds credentials to humans or long-running workloads. Agents are ephemeral session-scoped principals with no pre-established reputation.
Request shape is prompt-plus-tool-call, not a single API call. Policy has to evaluate "should this agent, making this tool call, under this prompt context, be allowed to do this?" — which is semantically richer than "does this role have this permission?"
Policy is evaluated twice per interaction — pre-I/O against the intent; post-I/O against the output. This catches cases where the input passes policy but the output contains data that should not cross a trust boundary (PII extraction, data exfiltration, protected-field leakage).
Every decision is captured for replay — future auditors / compliance tools can re-evaluate past policy decisions under new rules without re-running the agent.

Three-property composition¶

1. No long-lived credentials¶

Substrate: concepts/short-lived-credential-auth + concepts/ephemeral-credentials. Mechanism (not disclosed in the 2025-10-28 source): plausibly OIDC-federation-style token exchange — agent session presents a session assertion, receives a short-lived credential scoped to the specific tool / resource / operation / time window.

See siblings: - Fly.io AWS- without-access-keys (STS + OIDC federation, "dead in minutes") — the cross-cloud workload-identity mechanism. - Cloudflare OPKSSH (24-hour ephemeral SSH keys from OIDC login) — the human-to-SSH mechanism. - AAC is the agent-to-tool altitude of the same ephemeral- credential family.

2. Per-call policy enforcement before and after I/O¶

Load-bearing difference from traditional access control:

Pre-I/O check — against prompt + input + tool-call signature. "Should this agent be allowed to invoke this tool with these parameters on this resource?"
Post-I/O check — against tool-call output. "Does the response data cross a policy boundary (PII, protected fields, other-tenant data) that should be filtered / denied / flagged before returning to the agent?"

The two-sided check is the agent-specialisation feature — a single-sided check (pre-I/O only) doesn't catch the case where a well-formed query returns data the agent shouldn't see. A post-I/O check is the mechanism that makes dynamic content filtering a policy primitive rather than a debugging tool.

3. Fine-grained temporary access¶

"Grant AI agents fine-grained, temporary access to sensitive data." Two axes:

Fine-grained — narrower than role-scoped; ideally per-resource / per-operation. A typical pattern: a per-session capability that names the exact database rows / Iceberg table partition / MCP tool function the agent is authorised for.
Temporary — session-scoped or shorter; automatic revocation at session end or timeout. No orphan permissions.

Composition with the audit envelope¶

AAC makes every decision auditable and replayable. Per the canonical source: "Every prompt, action, and output is auditable, replayable." This binds AAC to the durable event log as audit envelope pattern — AAC is the policy layer, the audit envelope is the evidence substrate. They compose:

Every AAC policy check is an event on the log.
Every AAC credential issuance is an event on the log.
Every AAC denial / allow decision is an event on the log.
Replay of the log under new policy can re-evaluate historical decisions ("would this policy update have allowed / denied past interactions?").

Mechanism gap¶

The 2025-10-28 canonical source names the pattern without walking the mechanism. Not disclosed:

IdP / credential-minter. Is it a Redpanda-native component? Federated to customer IdP? Customer-configurable?
Policy engine. OPA? Custom? Rego? Cedar?
Token format. JWT? Macaroon-style attenuated capabilities? Custom?
Policy definition surface. Declarative config? Code? Policy-as-code version-controlled?
Binding to MCP tool invocations. How does the AAC check interpose on an MCP call without adding latency?
Policy evaluation point. In-process with the MCP proxy? Sidecar? Separate service?
Deny semantics. Hard-fail with error to agent? Silent-scrub of the denied field? Substitute with policy-compliant placeholder?

All deferred to future product disclosure.

Caveats¶

Pattern named, mechanism absent. At the 2025-10-28 source altitude, AAC is a positioning artefact rather than an implementation artefact. Future Redpanda posts will presumably unpack the mechanism.
Pre-I/O policy is state-of-the-art difficult. Evaluating policy against a natural-language prompt + tool-call parameters requires either (a) structured agent intent (prompt-engineering discipline in the agent framework — push policy-relevant fields to structured args) or (b) LLM-based policy evaluation (brittle, expensive, hard to audit). Neither is engaged by the canonical source.
Post-I/O policy is content-filtering. The output-side check requires understanding the semantic content of the tool response, not just its syntactic shape. Classic dynamic content filtering territory — hard at scale, easy to defeat with paraphrase, trivially expensive if every call round-trips through an LLM classifier.
Credential issuance latency. Minting a short-lived credential per tool call adds latency — canonical mitigation is session- scoped credentials rather than per-call, but session-scoped weakens the fine-grained axis.
Policy evolution breaks replay. If the policy engine changes between time-of-interaction and time-of-replay, the replay result differs from the original — which is the point (new policy would catch previously-allowed behaviour) but breaks exact-replay guarantees. Engineers must distinguish behavioural replay (what would happen under current policy) from audit replay (what actually happened under historical policy).
No substitute for model governance. AAC controls what an agent can do; it doesn't control whether the agent should do it in a higher sense. Complements concepts/ai-agent-guardrails rather than substituting.
Composes poorly with external agents. Agents running in third-party frameworks (OpenAI Assistants, Anthropic Claude API) without in-session policy hooks have to route through governed MCP proxies ("governed proxies" in the canonical source) for AAC to apply — the agent-outside-ADP case has weaker policy-check fidelity than agent-inside-ADP.

Contrasts and siblings¶

patterns/credentialed-proxy-sandbox is the Fly.io- canonicalised peer pattern — credentials held by a proxy the agent routes through, not by the agent itself. AAC is the policy-enforcement complement to the credential-holding substrate.
patterns/allowlisted-read-only-agent-actions is the narrower-privilege peer pattern — start with read-only allowlist, broaden as trust is established. AAC is the more general framing.
patterns/central-proxy-choke-point is the enforcement- topology peer — AAC is easier to implement at a central choke-point (MCP proxy) than distributed across agents.
ABAC is the underlying access-control concept AAC specialises. ABAC evaluates policy over attributes of the subject, resource, action, environment — AAC fixes the subject to "agent session" and adds the pre-and-post-I/O evaluation axis.
Traditional RBAC is the what AAC departs from — role- based access control requires stable, long-lived roles that accumulate permissions; agents are session-scoped principals so RBAC doesn't fit.

Seen in¶

sources/2025-10-28-redpanda-governed-autonomy-the-path-to-enterprise-agentic-ai — canonical wiki introduction. Names AAC as an "evolution of modern access control concepts" with three properties (no-long-lived-creds + pre-and-post-I/O-policy + fine-grained- temporary-access) + audit-replay composition. Mechanism not disclosed.
sources/2026-04-14-redpanda-openclaw-is-not-for-enterprise-scale — Reinforces AAC's "no long-lived credentials" property with the "Don't give the dog your keys" framing and introduces the concepts/token-vault as AAC's credential-minting substrate. The 2026-04-14 Redpanda post compresses AAC + OBO + audit envelope into a four-component production stack where the token vault is the concrete implementation substrate under AAC's property #1. Verbatim: "A token vault handles credentials out-of-band. The agent never holds your Salesforce token directly. When it needs to take an action, the gateway requests a short-lived, scoped token from the vault for exactly that operation." Mechanism still not disclosed at token-format / protocol altitude, but the architectural decomposition (vault as distinct component vs. gateway) is canonicalised here for the first time.