PaperlayerView exact revision on arXiv

Source-linked AI summary

API Secrets Should Never Become Tokens in the LLM's Vocabulary: A Threat Analysis of API Credential Handling in LLM Agent Systems and an Empirical Evaluation of a Vault-Mediated Execution Boundary

Patrick Kenney, Hadi Ahmadi, Denis Lusson, Donald Nguyen, Gurbinder Gill

arXiv:2609.33371v1cs.CRcs.AIcs.LG

TL;DR

LLM agents connected to enterprise services face credential exposure because secrets entering model context can spread into persistent systems, while the execution boundary remains less examined. The paper formalizes that threat, describes vault-mediated authentication, and evaluates it in controlled experiments. All 16 probes met their expected outcomes, while a misconfigured connector showed that centralized custody does not ensure correct authentication configuration.

  • Problem

    LLM agents’ persistent contexts and connected tools create credential-handling risk, while the execution boundary governing where credentials reside during authenticated calls has received less attention.

    Source: §1 · p. 1

  • Method

    The paper formalizes a credential-exposure threat chain and evaluates a vault-mediated execution boundary through two black-box experiments with predefined probe expectations.

    Source: §1 · p. 1, §5 · p. 3

  • Results

    All 16 evaluated probes met their expected security outcomes, including an authenticated GitHub request without a credential in the executing module and a secure failure for a misconfigured connector.

    Source: §6 · p. 4, §6.1 · p. 4, §6.5 · p. 4

  • Takeaways & Limitations

    Vault mediation can keep reusable credentials outside agent-visible runtime state, but least privilege, action authorization, human approval, redaction, rotation, and configuration validation remain necessary.

    Source: §10 · p. 6

    The purposive 16-probe black-box evaluation supports no prevalence estimates, omits several attack paths, and tests the positive control on only one connector.

    Source: §9 · p. 5

Abstract

from arXiv · show

Tool-using large language model (LLM) agents turn credential hygiene from a storage problem into an execution-security problem. A key pasted into a prompt, or embedded in a system prompt or tool configuration, crosses from an authentication boundary into a data pipeline, where it may persist in conversation history, logs, memory stores, generated code, and error payloads. Prompt injection and excessive agency then convert passive disclosure into unauthorized action. This paper formalizes the credential-exposure threat chain for agentic systems; synthesizes evidence from a platform secret-store incident, vendor-reported secret-sprawl measurement, and OWASP and NIST guidance; and describes a vault-mediated execution architecture in which the model selects a connector identifier while a trusted request boundary supplies authentication. We evaluate a production implementation, Corvic Security Vault, in two controlled black-box experiments. Across 16 probes spanning seven control domains, every probe met its expected outcome: an authenticated GitHub API request succeeded while the credential stayed absent from process environment values, caller-visible request headers, tested filesystem locations, three third-party echo services, and two unrelated API origins; both cloud instance-metadata endpoints were unreachable. We also report a negative result, a connector whose stored header mapping did not satisfy its provider's authentication contract, showing that centralized custody does not by itself guarantee correct configuration. Vault mediation removes several disclosure paths but is necessary rather than sufficient: least privilege, deterministic action authorization, human approval, telemetry redaction, and rotation remain independently required. The study is purposive and small, a functional security evaluation rather than a certification.

1 Introduction

Connecting LLM agents to APIs creates credential-handling risk because any secret entering model context can be copied into systems designed for retention. The paper identifies the underexamined execution boundary and presents a threat chain, evidence synthesis, vault-mediated architecture, and controlled evaluation.

1 Introduction

  • Connecting agents to enterprise APIs creates credential-handling risk because anything entering model context can reach multiple potential copy sites.Figure 1 depicts one introduction event creating durable copies that can later feed disclosure or misuse.Source: §1 · p. 1, Figure 1 · p. 2
  • Pasting an API key into chat is a boundary violation whose downstream blast radius is difficult to bound after duplication into retention-oriented systems.Source: §1 · p. 1
  • Prior work addresses prompt redirection and credential exposure separately, leaving the execution boundary—where credentials reside during authenticated calls—less examined.Source: §1 · p. 1
  • The paper contributes a structured threat chain, evidence synthesis, vault-mediated execution boundary, controlled experiments, threat assessment, deployment blueprint, and limitations account.Source: §1 · p. 1

2 Threat Model

The threat model traces credentials from introduction through propagation, triggering, execution, and persistence. It motivates keeping reusable credentials outside agent-visible state while retaining independent authorization controls.

2 Threat Model

  • A five-stage chain models credential exposure from introduction and propagation through trigger, execution, and persistence.A single introduction event can create durable copies before any API request is issued.Source: §2 · p. 2
  • Stage S3 is the best-studied link; tool-integrated agents remain vulnerable, while the evaluated architecture constrains tool-call authentication destinations rather than emitted calls.Prompt-boundary defenses and execution-boundary capability policies address different controls [5] [6] [7].Source: §2 · p. 2
  • Prior work reports common, long-lived secrets in public repositories and measurable insecure code-generation patterns, alongside model memorization and corpus poisoning risks.Meli et al.; Pearce et al. [21]; secret memorization [18] [17] [19]; corpus poisoning [22].Source: §2 · p. 2
  • Keeping reusable credentials out of model context and agent-visible runtime state can eliminate stages S1–S2 by construction.Source: §2 · p. 2
  • Custody alone does not address destructive actions by a secretless agent, so defenses also require independent authorization.Source: §2 · p. 2

3 Evidence and Related Work

The section distinguishes incident disclosure, vendor measurement, and standards or research guidance as separate evidence types. Together, they motivate separating the agent’s planner from credentials and independently authorizing actions.

3.1 Platform incident disclosure

  • Hugging Face disclosed unauthorized access involving Spaces secrets and advised affected users to rotate credentials, but the incident does not establish exfiltration or model disclosure.It highlights rotation, revocation, scoping, and auditing as platform requirements where credentials are concentrated.Source: §3.1 · p. 2

3.2 Vendor-reported measurement

  • GitGuardian identified 23,770,171 hardcoded secrets in 2024 public GitHub commits, a 25% year-over-year increase; 4.61% of 69.6 million scanned repositories contained at least one.These are detector-based vendor measurements, not a census or evidence that credentials were live or exploited.Source: §3.2 · p. 2

3.3 Security guidance

  • OWASP and NIST guidance treats disclosure, prompt leakage, excessive agency, and prompt injection as interacting risks, and recommends code-mediated privileged functions, minimum scopes, and bounded tool authority.Studies of live MCP ecosystems report over-broad privileges, tool-poisoning, malicious-server behaviors, and security weaknesses [13] [14] [15] [16].Source: §3.3 · p. 3
  • Separating the planner from credentials and authorizing actions independently applies least-privilege and complete-mediation principles to agents that process untrusted instructions.The described boundary has the agent name a connector while a trusted request boundary supplies authentication for its configured origin.Source: §3.3 · p. 3, Figure 2 · p. 3

4 Vault-Mediated Execution

Vault-mediated execution gives agent code connector identifiers rather than secret values, while the platform supplies credentials for configured origins. The design also specifies non-observability, origin binding, no ambient identity, and centralized connector lifecycle management.

4 Vault-Mediated Execution

  • Connector records hold the configured origin, type, non-secret configuration, mapped secret entries, and lifecycle state; agent code receives connector identifiers rather than secret values.The platform contract says credentials are injected as HTTP headers only for the connector’s declared host.Source: §4 · p. 3
  • P1 non-observability means executing code cannot read credentials from its environment, prepared request headers, or conventional on-disk locations.The properties are framed as testable from inside the sandbox without privileged access.Source: §4 · p. 3
  • P2 origin binding attaches credentials to requests to the connector’s configured origin rather than arbitrary destinations.The credential is injected for the connector’s declared host.Source: §4 · p. 3
  • P3 excludes ambient cloud workload identity from the sandbox, while P4 centralizes connector state, type, and scope.The platform’s contract states that no ambient cloud credentials are available to executing code.Source: §4 · p. 3

5 Experimental Method

The evaluation used two black-box experiments in a sandbox, granting each exactly one connector and scoring fixed probes against expectations declared before execution. Its paired controls, detection checks, and separate functionality scoring distinguish security outcomes from configuration failures.

5 Experimental Method

  • Two black-box experiments ran in the sandbox on 27 September 2026, each with one connector and probes carrying pre-declared binary expectations.Table 2 reports rates by control domain, with per-domain sample sizes from 1 to 5 and no meaningful confidence intervals for this purposive design.Source: §5 · p. 3, Table 2 · p. 4
  • Positive and negative controls tested declared-origin authentication alongside rejection of credential-bearing requests at echo services and an unrelated authenticated API.Both control types distinguish a passing security result from a sandbox with no network access.Source: §5 · p. 3
  • Credential detection used common-token prefix patterns, environment-name keywords, and searches of echo responses for authorization headers or token-shaped strings.Each probe was scored against its pre-declared expectation; connector functionality was assessed separately from security controls.Source: §5 · p. 3

6 Results

All 16 evaluated probes met their expected security outcomes. The results include successful authenticated GitHub access without a caller-held credential, non-observability and origin-binding checks, metadata endpoint timeouts, and a provider-configuration failure that remained secure.

6 Results

  • All 16 evaluated probes met their expected security outcome.Source: §6 · p. 4

6.1 Positive control (P2, functional)

  • An authenticated GitHub user-endpoint request returned HTTP 200 although the executing module supplied no Authorization header and contained no credential.This establishes vault authentication for the connector’s declared origin.Source: §6.1 · p. 4

6.2 Non-observability (P1)

  • No tested environment variable, readable process environment file, prepared GitHub request header, or tested filesystem credential path exposed a matching secret.The sandbox exposed 20 environment variables; none matched the tested high-confidence credential patterns.Source: §6.2 · p. 4

6.3 Origin binding and cross-origin non-disclosure (P2)

  • Three third-party echo services reflected no connector Authorization header or token-shaped string, while the unrelated OpenAI model-listing endpoint returned HTTP 401 for missing authentication.The credential was neither broadcast to arbitrary destinations nor reused across origins.Source: §6.3 · p. 4

6.4 Ambient identity (P3)

  • GCP metadata-token and AWS IMDSv1 requests timed out after 6 seconds, showing no cloud workload credential was reachable during the run.A timeout is not a formal network-isolation proof.Source: §6.4 · p. 4

6.5 Negative result: configuration is not custody

  • A St. Louis Fed connector call returned HTTP 400 because its stored secret mapped to an Authorization header while the provider required a query parameter.No credential was disclosed, but the result shows centralized custody does not validate provider authentication configuration.Source: §6.5 · p. 4

7 Threat-Model Assessment

The assessment uses ordinal expert judgments to prioritize threats before and after vault mediation. Over-privileged connectors and indirect prompt injection remain least reduced, requiring controls beyond credential custody.

7 Threat-Model Assessment

  • Ratings are ordinal expert judgments on a 1–5 scale, not calibrated probabilities; L × I is used only for prioritization.Source: §7 · p. 4
  • Over-privileged connector risk is barely reduced because vault custody does not narrow provider-side scopes.A valid token with write authority remains a valid token with write authority.Source: §7 · p. 4
  • Indirect prompt injection is reduced but not resolved, so least privilege and authorization outside the model remain necessary.The attack targets action selection rather than the secret itself; no published defense fully prevents it [3] [9].Source: §7 · p. 4

8 Deployment Blueprint

The deployment blueprint combines connector inventory and credential hygiene with independent controls over authority, action approval, egress, telemetry, and lifecycle. The evaluated probes met their expected outcomes, while the threat assessment indicates custody alone leaves residual risks.

8 Deployment Blueprint

  • Inventory each connector’s owner, environment, provider, authentication type, data classification, scopes, expiry, and rotation path.Source: §8 · p. 4
  • Eliminate direct credential pasting and minimize provider authority through narrow identities, scopes, and delegated tokens.The blueprint recommends separating read and write identities and preferring per-user OAuth over shared administrator tokens.Source: §8 · p. 4
  • Authorize actions at a deterministic policy point and require approval for transfers, deletion, privilege changes, bulk export, and other high-impact calls.Source: §8 · pp. 4–5
  • Every evaluated probe met its pre-declared expected outcome, as a controlled functional check rather than a statistical pass-rate estimate.Source: Figure 3 · p. 5
  • Three threats remain at or near the high-priority threshold after vault mediation, so credential custody alone does not retire them.Source: Figure 4 · p. 5
  • Allow-list egress destinations, prevent redirects from relocating credentials or sensitive results, and redact secrets from telemetry.Source: §8 · p. 5
  • Exercise OAuth refresh, expiry, revocation, disablement, offboarding, incident rotation, and downstream audit review.Red-team testing should cover injection, tool poisoning, cross-origin requests, error paths, retries, redirects, memory recall, and multi-agent handoff.Source: §8 · p. 5

9 Limitations

The evaluation is a small purposive black-box study, with several attack paths and platform properties left untested or unverified. The authors identify further conformance, isolation, audit, rotation, and independent testing as priorities.

9 Limitations

  • Sixteen purposively selected probes support no prevalence estimate, repeated-trial variance analysis, or concurrency-stress conclusion.The positive control exercised one connector, not every connector.Source: §9 · p. 5
  • Redirect chains, DNS rebinding, OAuth refresh capture, MCP session state, browser-tool paths, and adversarial compromise of a configured destination were not tested.Pattern-based detection may miss unknown credential formats, and network timeouts show non-reachability during the run rather than formal isolation.Source: §9 · p. 5
  • Encryption and key management, token-at-rest storage, tenant-isolation internals, audit completeness, access controls, deletion, rotation service levels, certifications, and broader request-policy semantics were not verified.Source: §9 · p. 5
  • Future work includes provider-contract conformance, policy-denial and redirect tests, per-tenant isolation verification, audit review, rotation measurement, and independent penetration testing.The authors identify running an established agent-injection benchmark against a vault-mediated deployment as the most valuable single extension.Source: §9 · pp. 5–6

10 Conclusion

The conclusion argues that reusable credentials should remain outside model-visible context and runtime state, with authenticated actions mediated by deterministic controls. The reported implementation achieved that separation in its tested configuration; experiments were conducted in the authors’ tenant, used read-only third-party requests, and sought no external vulnerabilities.

10 Conclusion

  • The conclusion rejects the model as an enforcement point and calls for deterministic identity, policy, and audit controls around authenticated actions.Source: §10 · p. 6
  • In the tested configuration, Corvic Security Vault let agent code call an authenticated service using a connector without holding a reusable credential.Unrelated origins received none.Source: §10 · p. 6

Reproducibility and Ethics

  • Both experiments ran in the authors’ tenant, third-party requests were read-only, and no external provider vulnerability was sought or exercised.Source: Reproducibility and Ethics · p. 6

Related papers

Loading 2609.33371v1…