Pattern A: Fetch a credential from a secrets vault, then use it in application code. The credential exists in application memory — it can be logged, debugged, extracted via XSS, copied from a debugger, captured by APM tools.
Pattern B: Request an action. The token is fetched, used, and discarded server-side. The application receives data — never the credential.
Most enterprises deploying AI agents use Pattern A. Here's why that's a problem.
The Architecture Matters More Than the Vault
HashiCorp Vault, AWS Secrets Manager, and CyberArk are excellent products. They encrypt secrets at rest, control access to secrets, and audit who retrieved what. None of them prevent the application from having the secret after retrieval.
In the traditional pattern, the vault is a locked cabinet. You open it, take the key, use the key, and — if you're disciplined — put it back. But while you hold the key, it's yours. In the ARIA pattern, you never hold the key. You ask someone in a locked room to use the key on your behalf and tell you the result.
Five Attack Surfaces You Inherit
1. Accidental logging
APM tools (Datadog, Splunk, New Relic) capture request payloads by default. A single console.log(response) leaks the token.
2. XSS extraction
Malicious scripts search localStorage, sessionStorage, and JavaScript variables. If the token is in memory — even temporarily — it's extractable.
3. Developer misuse
Engineers fetch production tokens, copy them from a debugger, use them in Postman. The vault logged the retrieval. It has no visibility into what happened next.
4. Error handler leakage
Exception stack traces include local variable values. A crash report containing an OAuth token is a credential leak.
5. Monitoring exposure
APM tools automatically capture HTTP headers, including Authorization: Bearer .... The token is now in your monitoring system's data store.
The Three-Zone Architecture
The critical property: no code path returns credentials from Zone 3 to Zone 1. This is enforced architecturally — workflow output schemas exclude credential variables. It's not a policy developers must remember. It's a property of the system.
The Agent Scenario That Proves the Point
An AI agent with a read-only PDP policy is acting on behalf of a user whose Jira OAuth token has read and write scopes.
Traditional approach
Agent gets the token. Token has write scope. Agent calls write API. It works. The vault is irrelevant.
ARIA approach
PDP evaluates delegation — read-only. Denies. Token never fetched. Signed receipt records the denial.
Authorization happens before credential retrieval. This is the property that matters.
One Question
If your AI agent's OAuth token appeared in a Datadog trace tomorrow, would you know? Would you even be looking?
With ARIA's OAuth Vault, the question is moot. The token was never in the trace. It was never in the application. It was never anywhere your code could reach.
ARIA is EmpowerNow's runtime execution control platform. The OAuth Vault is one of six interlocking controls providing identity, authorization, budget enforcement, and tamper-evident audit.
Next in this series: MCP Is the Interface. Governance Is the Product.