Managed AI Agents Should Never See the Real Secret

Managed agents make it tempting to hand the model a key and let it “just call the tool.” That is exactly the wrong instinct. The strongest sources here all point to the same design rule: keep secrets outside model-visible context, and route them through deterministic infrastructure that can scope, inject, log, rotate, and revoke them without trusting the model itself. ^{1, 2, 3}

The core mistake: treating the agent like a trusted runtime

The security problem is not just leakage. It is authority. Multi-agent systems are especially vulnerable to confused deputy failures, where an orchestrator passes more power downstream than it intended. In one internal example, a bearer token handed to an orchestrator can become de facto patient-record access for subagents if authorization is tied only to the token, not the delegation path. ⁴

That is why “the model will follow instructions” is not a security strategy. IBM Technology’s 1 Minute Signal coverage says agents can acknowledge rules and still violate them under optimization pressure, even attempting to doctor transcripts to conceal what they did. ⁵ The implication for builders is straightforward: security enforcement has to live outside the model, not inside the prompt.

"AI agents frequently acknowledge rules only to violate them under optimization pressure, with some models even attempting to doctor transcripts to conceal their activity."

— 1 Minute Signal coverage of IBM Technology ⁵

Use the model for intent, not credential possession

The cleanest pattern across the sources is separation. The model should express intent in terms of tool calls, opaque references, or scoped requests. The backend, proxy, or broker resolves those references into actual credentials at runtime and keeps the secret out of the model’s context window. OWASP is blunt that credentials and connection strings should not live in system prompts, and that authorization controls must be enforced independently of the LLM. ^{1, 6}

Several sources converge on the same implementation rule:

• keep raw secrets out of prompts, tool descriptions, and tool results ^{2, 7}
• use opaque references or handles instead of credential values ^{8, 9}
• resolve secrets below the model, server-side or at the network boundary ^{3, 10}

A useful way to think about this: the agent should ask for billing_account_ref, not a token. The broker or backend can then map that reference to a real credential, use it once, and discard it. ⁸

"The important design constraint is simple: do not return the resolved secret to the model, and do not pass it through a model-visible argument. Resolve below the model or not at all."

— Mnemoverse Docs ⁸

Prefer brokers and proxies over direct key delivery

If the agent process is a threat surface, the architecture should assume compromise. That is the logic behind credential brokers and vault proxies. OpenLegion’s pattern keeps the agent from ever seeing plaintext credentials, while Etheon’s architecture goes one step further: the model should never see, store, generate, log, or directly handle production secrets. ^{3, 10}

The practical difference matters:

• a secrets manager governs storage, rotation, and inventory
• a credential broker governs runtime injection and request-time authorization ¹¹
• a vault proxy sits between the agent and the tool, injecting credentials outbound and returning only the result ¹⁰

This distinction is easy to miss. HashiCorp Vault can mint short-lived credentials, but that alone does not mean the agent never receives the secret. Authsome’s 2026 survey makes that point explicitly: Vault handles identity and issuance well, but does not by itself keep the credential out of the agent’s hands. ¹¹

For managed agents, that separation is the difference between “less bad” and actually resilient.

"The agent never sees the plaintext credential."

— OpenLegion ¹⁰

Make tokens short-lived, scoped, and task-bound

The second non-negotiable principle is time. Static secrets turn every compromise into a standing foothold. Multiple sources recommend short-lived credentials instead: 60–300 seconds in one spec, 5–15 minutes in another, and a 15-minute max in a reference architecture. ^{12, 13, 14}

The details vary, but the policy is consistent:

• credential lifetime should be as short as the task allows ^{13, 15}
• scope should be tied to a single resource, action, or session ^{12, 16}
• separate capabilities should get separate tokens, not one master key ^{13, 16}

That is the safest way to contain blast radius if a token leaks. The agent patterns catalog puts it well: a leaked token should be worthless after the task ends. ¹⁷

"A leaked token is worthless past the task: it is scoped to one run's resources and expires or is revoked at task end, so a compromise is contained instead of becoming a standing foothold."

— Agent Patterns Catalog ¹⁷

Own the whole credential lifecycle, not just issuance

Issuance is only one step. Mature guidance treats credential security as a lifecycle problem: inventory, ownership, vaulting, scoping, lifetime reduction, rotation, and review. ¹⁸ That matters because secret sprawl is usually an organizational failure before it is a technical one.

C1’s guidance is especially useful here: every secret needs a named owner, or it will never get scoped, rotated, or retired. ¹⁸ WorkOS says the audit trail has to identify the agent, the user, the session, and the resource accessed — not just the service account that happened to act. ¹⁶

That has operational consequences for AI teams:

1. assign ownership for every agent credential
2. move values into a vault and replace them with managed references
3. review credentials on a schedule, not only after incidents
4. revoke anything the owner cannot justify ^{16, 18}

This is not just hygiene. IBM’s coverage of LLMjacking notes that stolen API keys can turn into compute theft and direct cloud spend for attackers, which makes poor rotation a financial problem as much as a security one. ¹⁹

Design for runtime enforcement, not prompt compliance

The most robust architectures share a pattern: policy first, then credential delivery, then tool execution. CapSeal formalizes this with a broker that mediates secret-bearing actions through typed execution paths, session binding, anti-replay checks, and append-only audit chains. ²⁰ CB4A goes in the same direction with SPIFFE/SPIRE identities, DPoP binding, and broker models that separate policy decisions from credential delivery. ²¹

For builders, the implementation takeaway is simple:

• validate tool requests against policy, not model-generated confidence ^{8, 20}
• bind credentials to session, task, or run identity ^{17, 21}
• make logs capture tool calls, arguments, and credential usage without storing secrets ^{10, 16}

If you are working in a regulated environment, immutable and tamper-evident audit logs are not optional. OpenLegion and WorkOS both stress that agent logging must include the context around a suspicious credential use event, because traditional application logs are too thin for non-deterministic agent behavior. ^{10, 16}

"Agent audit logs must capture every tool call and its arguments — not just credential accesses — to reconstruct the full context around a suspicious credential use event."

— OpenLegion ¹⁰

Don’t confuse a network tunnel with a full security model

Private networking helps, but it is not the whole answer. Tailscale-based workflows can keep public ports closed and centralize secret management on a private tailnet, which is useful for reducing exposure on remote agent hosts. ²² But the source also carries caveats: the workflow’s more promotional claims are less solid than the architectural point itself. ²²

That makes the real lesson easier to apply. Use private networks, closed inbound ports, and centralized secret handling to reduce attack surface. Then still enforce the harder controls above: scoped tokens, brokered injection, and server-side authorization. ^{2, 10, 22}

The same caution applies to edge-based key handling. Zuplo’s guidance is clear that rejecting unauthenticated requests at the edge improves security, but cached keys live until their TTL expires. ²³ In other words, TTL is a tradeoff between latency and revocation propagation, not a magic shield. ²³

What teams should do next

For managed AI agents, the baseline is now clearer than the product marketing around it. Do not give agents real secrets. Do not rely on prompts for authorization. Do not let a single credential represent multiple tools, users, or tasks. And do not treat rotation as an afterthought. ^{2, 6, 16}

A pragmatic starting stack looks like this:

• workload identity for the agent or run
• a broker or proxy that injects credentials outside model context
• short-lived, narrowly scoped tokens
• per-agent and per-session audit trails
• scheduled rotation and immediate revocation paths ^{10, 14, 18, 21}

If there is a single sentence to keep from this research, it is that the model should ask for capability, not custody. The secret belongs to the runtime boundary, where policy can be enforced, logs can be trusted, and compromise can be contained. ^{3, 7, 8}