Paper deep dive
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
Intelligence
Status: not_run | Model: - | Prompt: - | Confidence: 0%
Entities (0)
Relation Signals (0)
No relation signals yet.
Cypher Suggestions (0)
No Cypher suggestions yet.
Abstract
Abstract: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.
Tags
Links
- Source: https://arxiv.org/abs/2609.33371v1
- Canonical: https://arxiv.org/abs/2609.33371v1
Trouble viewing inline? Open PDF directly â
Full Text
32,808 characters extracted from source content.
Expand or collapse full text
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 KenneyHadi AhmadiDenis Lusson pkenney@corvic.ai hadi@corvic.ai denis@corvic.ai Donald NguyenGurbinder Gill ddn@corvic.ai gill@corvic.ai Corvic AI Research Abstract Tool-using large language model (LLM) agents convert credential hygiene from a storage problem into an execution-security problem. When a user pastes an API key into a prompt, or a developer embeds one in a system prompt or tool configuration, the secret crosses from an authentication boundary into a data pipeline where it may be retained in conversation history, logs, memory stores, generated code, and error payloads. Prompt injection and excessive agency can then convert passive disclosure into unauthorized action. This paper (i) formalizes the credential-exposure threat chain for agentic systems, (i) synthesizes evidence from a platform secret-store incident, vendor-reported secret-sprawl measurement, and OWASP/NIST guidance, (i) describes a vault-mediated execution architecture in which the model selects a connector identifier while a trusted request boundary supplies authentication, and (iv) reports two controlled black-box experiments against a production implementation of that architecture, Corvic Security Vault. Across 16 evaluated probes spanning seven control domains, every probe met its expected security outcome: an authenticated GitHub API request succeeded while the credential remained 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, which demonstrates that centralized custody does not by itself guarantee correct configuration. We conclude that vault mediation eliminates 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; it is a functional security evaluation, not a certification. Keywords: LLM security; agentic AI; API credentials; secrets management; prompt injection; least privilege; MCP 1 Introduction The deployment pattern that makes LLM agents commercially useful, namely connecting them to enterprise APIs, SaaS plat- forms, internal services, and Model Context Protocol (MCP) servers, is the same pattern that makes them a credential- handling risk. A conventional application confines a secret to a secrets manager and a small number of trusted processes. An agentic application introduces a probabilistic planner, a persistent conversation, retrieval over untrusted documents, tool schemas, execution traces, inter-agent messages, and user- visible outputs. Each is a potential copy site for anything that enters the modelâs context. The practical consequence is that the common user behavior of pasting an API key or access token directly into a chat interface is not merely poor hygiene. It is a boundary violation whose blast radius is difficult to bound after the fact, because the credential is duplicated into systems that were designed for retention and retrieval rather than for secrecy. Existing research establishes the two halves of this prob- lem separately. One body of work shows that instructions embedded in retrieved content can redirect an LLM applica- tionâs behavior [1,2,3,4], and that tool-using agents inherit this exposure through every document and API response they read [8,9,10]. A second body of work shows that credentials are abundant in the artifacts these systems consume and pro- duce [23,21], and that models can surface memorized secrets from their training data [18,17,19]. What has received less attention is the execution boundary between them: where the credential physically resides at the moment an agent makes an authenticated call, and what an attacker who controls the agentâs instructions can therefore reach. This paper makes four contributions: 1.A structured threat chain (§2) describing how a credential propagates from introduction to downstream compromise in agentic systems. 2.A synthesis of the available evidence (§3), carefully sepa- rating incident disclosure, vendor-reported measurement, and security guidance. 3. A description of a vault-mediated execution boundary (§4) as implemented in Corvic Security Vault, based on inter- nally observable platform contracts. 4. Two controlled experiments and their results (§5â§6), a threat-model assessment (§7), a deployment blueprint (§8), and an explicit account of limitations (§9). Scope and safety boundary. All experiments were non- destructive and read-only with respect to third-party services. 1 arXiv:2609.33371v1 [cs.CR] 27 Sep 2026 API Secrets Should Never Become Tokens in the LLMâs Vocabulary2 Raw key pasted Chat history Logs / traces Memory / RAG Injection / leakage Downstream compromise Figure 1: The direct-paste anti-pattern. One introduction event creates several durable copies in systems designed for retention, any of which can later feed disclosure or misuse. No secret value was printed, copied, transmitted to an unautho- rized destination, or validated outside its configured service. The experiments tested for the presence of credential mate- rial and for authentication behavior; they did not attempt to recover, reconstruct, or exfiltrate any secret. 2 Threat Model We model credential exposure in agentic systems as a five- stage chain. Figure 1 illustrates the propagation stage, where a single introduction event produces multiple durable copies before any API request is issued. S1: Introduction. A user message, prompt template, source file, notebook, tool definition, or MCP server configuration contains a reusable secret. S2: Propagation. Model context, conversation history, execution logs, memory and vector stores, generated code, and error payloads duplicate it. S3: Trigger. Direct or indirect prompt injection, system-prompt extraction, a malicious tool response, or ordinary model error requests disclosure or misuse. S4: Execution. A broadly privileged token authorizes reads, writes, deletion, publication, compute consumption, or lateral movement. S5: Persistence. A long-lived bearer token is replayable outside the original agent, user, session, or enterprise control plane. Stage S3 is the best-studied link. Indirect prompt injection was demonstrated against real LLM-integrated applications by Greshake et al. [1], following earlier work on direct instruction override [2]; Liu et al. [3] subsequently formalized the attack class and benchmarked ten defenses, finding none robust. For agents specifically, InjecAgent [10] and AgentDojo [9] show that tool-integrated agents remain vulnerable in realistic multi- step environments, and Fang et al. [11] show that agents with tool access can carry out end-to-end intrusions autonomously. Proposed defenses operate either on the prompt boundary, by structurally separating instructions from data [5,6], or on the execution boundary, by extracting control and data flow from the trusted query and enforcing capability policies at tool-call time [7]. The architecture evaluated here is complementary to the latter: it constrains what a tool call can authenticate to, rather than which tool call is emitted. Stage S5 has an empirical basis as well. Meli et al. [23] showed that secrets in public repositories are both common and long-lived, and Pearce et al. [21] showed that code- generation models emit insecure patterns at measurable rates, which matters when an agent writes the integration code. Models can also surface secrets they memorized during train- ing [18,17,19], and corpora themselves can be poisoned at practical cost [22]. Two properties of this chain motivate the architecture in §4. First, stages S1âS2 are eliminable by construction: if no reusable credential ever enters model-visible context or agent-visible runtime state, most copy sites never receive one. Second, stages S4âS5 are not addressed by custody alone: an agent holding no secret can still invoke an authorized but destructive operation. Any credible defense must therefore combine credential separation with independent authorization. 3 Evidence and Related Work We deliberately separate three classes of evidence, which are frequently conflated in vendor literature: a platform in- cident disclosure, a vendor-reported measurement, and peer- reviewed research and standards guidance. 3.1 Platform incident disclosure On 1 June 2024, Hugging Face disclosed that it had detected unauthorized access to its Spaces secrets and advised affected users to rotate credentials [36]. This supports a bounded claim: a hosted AI platform detected access involving its secret store and treated configured credentials as potentially exposed. It does not establish that every secret was exfiltrated or abused, and it is not an instance of a model spontaneously revealing a credential. Its relevance is that hosted agent platforms con- centrate credentials, making rotation, revocation, scoping, and audit first-order platform requirements. 3.2 Vendor-reported measurement GitGuardian reports that its detectors identified 23,770,171 hardcoded secrets in public GitHub commits made during 2024, a 25% year-over-year increase, and that 4.61% of the 69.6 million public repositories it scanned contained at least one secret [24]. This is a vendor measurement, not a census: detector coverage, secret definitions, deduplication policy, and validity checking all affect the figure, and detection does not establish that a credential was live or exploited. Interpreted conservatively, it establishes that agent developers operate in an environment with a large pre-existing supply of exposed credentials. The academic record is consistent with this: Meli et al. [23] found secrets in public GitHub repositories at scale and observed that many remained valid long after commit, which is the property that makes a leaked credential useful to an attacker. 3.3 Security guidance OWASPâs 2025 LLM guidance treats sensitive-information disclosure [31], system-prompt leakage [33], and excessive API Secrets Should Never Become Tokens in the LLMâs Vocabulary3 Agent intent, plan no secret Tool request host, method, arguments Vault boundary connector by ID inject at request origin binding lifecycle state Service authorized call response returns; reusable secret does not Figure 2: Vault-mediated execution. The agent names a connector; the trusted request boundary supplies authentication for the connec- torâs configured origin. The credential is never a value the agent holds. agency [32] as distinct but interacting risks, and recommends handling privileged functionality in code rather than expos- ing tokens to the model, executing tools in the userâs context, and applying minimum scopes. OWASPâs MCP Top 10 entry MCP01 specifically names token mismanagement and secret exposure, highlighting hard-coded credentials, long-lived to- kens, secrets retained in model memory or protocol logs, and retrieval of such material through prompt recall or log in- spection [34]. NISTâs Generative AI Profile distinguishes direct from indirect prompt injection and notes downstream consequences for interconnected systems [29]; NISTâs ad- versarial machine learning taxonomy classifies these attack classes and their mitigations [30], and MITRE ATLAS cata- logues observed techniques against AI-enabled systems [35]. Research on tool-using agents further motivates bounding and evaluating agent tool authority rather than trusting model output [8, 12]. Measurement work on MCP deployments substantiates the protocol-level concern. Studies of live MCP ecosystems re- port over-broad API privileges granted to servers [14], prac- tical tool-poisoning against real servers [13], a taxonomy of malicious-server behaviors [15], and ecosystem-wide security weaknesses [16]. The guidance converges on a single architectural prescrip- tion: separate the planner from the credential, and autho- rize the action independently of the plannerâs prose. This is not a new principle so much as an old one applied to a new component. Saltzer and Schroederâs least-privilege and complete-mediation principles [26] and Hardyâs confused- deputy problem [27] describe exactly the failure mode of an agent that holds broad authority and accepts instructions from an untrusted source; NISTâs zero trust architecture generalizes the response [28]. 4 Vault-Mediated Execution Corvic Security Vault exposes each external integration as a connector record carrying a configured API origin, a con- nector type (api,oauth, ormcp), non-secret configuration, named secret entries with their header mappings, and lifecy- cle state (for exampleactive,expired, or unconfigured). Agent-executed code receives only a list of connector identi- fiers, not secret values. The platformâs own execution contract states that no ambient cloud credentials are available to that code and that connector credentials are injected as HTTP headers for the connectorâs declared host. Table 1: Experimental design. Each experiment was granted a single connector identifier and issued a fixed probe set. E1: runtime exposureconnector: FRED declared origin api.stlouisfed.org Probe setEnvironment variable names and values; the process environ- ment file; 12 well-known credential paths; secret-mount globs; AWS IMDSv1 and GCP metadata endpoints; declared-host call; three echo services; two unrelated APIs E2: host-bound functionconnector: GitHub declared origin api.github.com Probe setAuthenticated user endpoint; caller-prepared request headers; credential pattern scan over the environment; two echo services; one unrelated authenticated API This yields four security properties that are testable from inside the sandbox without privileged access: P1.Non-observability. Executing code cannot read the credential from its environment, its own prepared request headers, or conventional on-disk credential locations. P2. Origin binding. The credential is attached to requests to the connectorâs configured origin and not to arbitrary destinations. P3.No ambient identity. The sandbox holds no cloud work- load identity that could substitute for the vault. P4.Centralized lifecycle. Connector state, type, and scope metadata are managed centrally and surfaced as meta- data rather than as secret values. 5 Experimental Method We evaluated P1âP4 with two black-box experiments exe- cuted inside the platformâs sandboxed Python environment on 27 September 2026 (UTC). Each experiment was granted ex- actly one connector, and each probe carried an explicit binary expectation defined before execution. Controls. The design pairs a positive control (an authenti- cated call to the connectorâs declared origin must succeed) with negative controls (echo services must not receive an Authorizationheader; an unrelated authenticated API must report missing authentication). Without both, a passing result would be indistinguishable from a sandbox with no network access. Detection. Credential presence was tested with high- confidence prefix patterns for common token formats and with keyword matching over environment variable names. Echo- service responses were searched for authorization headers and token-shaped strings. Detection results are reported as counts and booleans only. Classification. Each probe was scored against its pre- declared expectation and assigned to one of seven control domains. Connector functionality was scored separately from security controls, so that a provider-contract failure could not be recorded as a security pass or a security failure. API Secrets Should Never Become Tokens in the LLMâs Vocabulary4 Table 2: Evaluated probes by control domain. Rates are reported for completeness; per-domainnranges from 1 to 5 and no confidence interval is meaningful for this purposive design. Control domainnPassFail Host-bound credential injection550 Process environment220 Filesystem mounts220 Cross-origin non-disclosure220 Credential non-observability220 Cloud metadata isolation220 Authorized connector function110 Total16160 6 Results All 16 evaluated probes met their expected security outcome (Table 2, Figure 3). 6.1 Positive control (P2, functional) In E2, an authenticated GET of the GitHub user endpoint (api.github.com/user) returned HTTP 200 with an authen- ticated identity while the executing module supplied no Authorizationheader and contained no credential. This establishes that the vault performed authentication for the connectorâs declared origin. 6.2 Non-observability (P1) The sandbox exposed 20 environment variables.None had a secret-suggestive name, and none matched the high- confidence credential patterns tested. The process environ- ment file /proc/self/environ was readable (634 bytes) but contained no matching secret. None of the 12 tested creden- tial paths existed, and secret-mount globs returned no entries. Arequestsobject prepared by the calling process for the GitHub endpoint carried noAuthorizationheader, indi- cating that injection occurs outside the processâs own view of the request. 6.3 Origin binding and cross-origin non-disclosure (P2) Three third-party echo services (httpbin, Postman Echo, httpbingo) returned HTTP 200 and reflected no connec- torAuthorizationheader and no token-shaped string; the reflected requests identified the caller only as the plat- form sandbox. Calls to the OpenAI model-listing endpoint (api.openai.com/v1/models) returned HTTP 401 with a missing-authentication error in both experiments, including while a GitHub connector was attached. The credential was therefore neither broadcast to arbitrary destinations nor reused across origins. 6.4 Ambient identity (P3) Requests to the GCP metadata service-account token endpoint and to AWS IMDSv1 both timed out after 6 s. Within this run, no cloud workload credential was reachable. We note that a timeout demonstrates non-reachability during the run rather than constituting a formal network-isolation proof. Table 3: Directional threat assessment.LĂIis an ordinal prioritiza- tion score, not a probability. #ThreatBaseResid. 1Secret pasted into prompt254 2Indirect prompt injection2512 3Cross-origin credential exfiltration204 4Credential discovery in runtime204 5Over-privileged connector2015 6Long-lived token replay208 7Telemetry or error leakage168 8Connector misconfiguration96 6.5 Negative result: configuration is not custody In E1, the declared-host call to api.stlouisfed.org returned HTTP 400 with the message that theapi_keyvariable was not set. The connectorâs stored secret entry was mapped to anAuthorizationheader, whereas the provider requires a query parameter. This is a functional failure with a secure outcome: no credential was disclosed, and no unauthorized access occurred. It is reported because it isolates an important limit. Centralizing custody does not validate each providerâs authentication contract, and a misconfigured connector fails closed but also fails to work. 7 Threat-Model Assessment Table 3 and Figure 4 summarize a directional assessment of eight threats before and after vault mediation. Ratings are ordinal expert judgments on a 1â5 scale, not calibrated probabilities; the productLĂ Iis used only for prioritization. Two threats move least. Over-privileged connector 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. Indirect prompt injection is reduced but not resolved, because the attack targets the agentâs action selection rather than the secret itself, and no published defense fully prevents it [3,9]. Both residuals must be addressed by least privilege and by authorization outside the model. 8 Deployment Blueprint 1. Inventory. Record owner, environment, provider, authenti- cation type, data classification, scopes, expiry, and rotation path per connector. 2.Eliminate direct paste. Detect and block credential pat- terns in chat input, prompts, notebooks, tool schemas, and logs; offer a one-click connector path instead. 3.Minimize provider authority. Separate read and write identities, prefer per-user OAuth over shared administrator tokens, and bind audience and resource where supported. OAuthâs own security guarantees depend on deployments following its recommendations [25]; treat delegated tokens as narrow capabilities [27], not as ambient authority. 4.Authorize outside the model. Validate host, method, path, schema, tenant, volume, and user entitlement at a determin- istic policy point, as complete mediation requires [26,28]. API Secrets Should Never Become Tokens in the LLMâs Vocabulary5 Figure 3: Evaluated probes by control domain, from experiments E1 and E2. Every probe met its pre-declared expected outcome. The result is a controlled functional check on a small purposive sample, not a statistical pass-rate estimate. Figure 4: Assessed change in ordinal priority score for the eight threats of Table 3, sorted by residual score. Each pair joins the baseline score to the residual score after vault mediation, with the reduction annotated at right. Three threats remain at or near the high-priority threshold, so credential custody alone does not retire them. Control-flow and capability approaches such as CaMeL [7] show this can be enforced systematically rather than heuris- tically. 5.Require approval. Gate transfers, deletion, external publi- cation, privilege change, bulk export, production mutation, and high-cost calls. 6.Control egress. Allow-list destinations and prevent redi- rects or tool output from relocating credentials or sensitive results. 7.Redact telemetry. Strip authorization headers, cookies, query secrets, and signed URLs; retain connector identifier, policy decision, and correlation identifiers. 8.Exercise lifecycle. Test OAuth refresh and expiry, revoca- tion, connector disablement, offboarding, incident rotation, and downstream audit review. 9. Red-team continuously. Cover direct and indirect in- jection, tool poisoning, cross-origin requests, error paths, retries, redirects, memory recall, and multi-agent handoff. Published agent benchmarks [9,10,13] supply reusable test cases. 9 Limitations The evaluation is black-box and purposive. Sixteen probes cannot support prevalence estimates, and the design includes no random sampling, no repeated-trial variance, and no con- currency stress. We did not test redirect chains, DNS rebind- ing, OAuth refresh capture, MCP session state, browser-tool paths, or adversarial compromise of a configured destination. Pattern-based detection can miss unknown credential formats. Network timeouts evidence non-reachability during the run rather than a formal isolation guarantee. The positive control exercises one connector, not every connector. The following properties were not verified and are not claimed: encryption algorithms and key management; token- at-rest storage; tenant-isolation internals; audit-log complete- ness; administrative access controls; deletion guarantees; ro- tation service levels; compliance certifications; and request- policy semantics beyond the tested hosts. Future work should add provider-contract conformance tests, explicit policy-denial tests, redirect and egress handling, API Secrets Should Never Become Tokens in the LLMâs Vocabulary6 per-tenant isolation verification, audit-log review, rotation tim- ing measurement, and independent penetration testing. Run- ning an established agent-injection benchmark [9,10] against a vault-mediated deployment would measure the residual in Table 3 rather than assess it, and is the most valuable single extension of this work. 10 Conclusion The enterprise question is not whether an LLM can be in- structed to keep a secret; it cannot be trusted as an enforce- ment point. The correct design keeps reusable credentials outside the modelâs vocabulary and outside agent-visible run- time state, then mediates every authenticated action through deterministic identity, policy, and audit controls. In the con- figuration tested, Corvic Security Vault implemented a strong version of that separation: agent code named a connector and completed an authenticated service call without ever holding a reusable credential, while unrelated origins received none. The residual agenda of least privilege, action authorization, human approval, redaction, rotation, configuration validation, and continuous verification is where the remaining risk lives. Reproducibility and Ethics Both experiments were executed in the authorsâ own tenant against connectors configured for that tenant. All third-party requests were read-only. No secret value was printed, stored, transmitted to an unauthorized destination, or tested against any service other than its configured provider. Results are reported as counts, status codes, and booleans. No third-party system was attacked, and no vulnerability in any external provider was sought or exercised. References [1]K. Greshake, S. Abdelnabi, S. Mishra, C. Endres, T. Holz, and M. Fritz. Not What Youâve Signed Up For: Compromising Real-World LLM-Integrated Applications with Indirect Prompt Injection. In Proc. 16th ACM Workshop on Artificial Intelligence and Security (AISec â23), p. 79â90, 2023.https://doi.org/10.1145/3605764. 3623985 [2]F. Perez and I. Ribeiro. Ignore Previous Prompt: Attack Techniques For Language Models. arXiv:2211.09527, 2022.https://arxiv. org/abs/2211.09527 [3]Y. Liu, Y. Jia, R. Geng, J. Jia, and N. Z. Gong. Formalizing and Bench- marking Prompt Injection Attacks and Defenses. In 33rd USENIX Security Symposium, p. 1831â1847, 2024.https://w.usen ix.org/conference/usenixsecurity24/presentati on/liu-yupei [4]Y. Liu, G. Deng, Y. Li, K. Wang, Z. Wang, X. Wang, T. Zhang, Y. Liu, H. Wang, Y. Zheng, and Y. Liu. Prompt Injection Attack against LLM-Integrated Applications. arXiv:2306.05499, 2023.https:// arxiv.org/abs/2306.05499 [5]S. Chen, J. Piet, C. Sitawarin, and D. Wagner. StruQ: Defending Against Prompt Injection with Structured Queries. arXiv:2402.06363, 2024. https://arxiv.org/abs/2402.06363 [6]K. Hines, G. Lopez, M. Hall, F. Zarfati, Y. Zunger, and E. Kiciman. Defending Against Indirect Prompt Injection Attacks With Spotlight- ing. arXiv:2403.14720, 2024.https://arxiv.org/abs/2403. 14720 [7]E. Debenedetti, I. Shumailov, T. Fan, J. Hayes, N. Carlini, D. Fabian, C. Kern, C. Shi, A. Terzis, and F. Tramèr. Defeating Prompt Injections by Design. arXiv:2503.18813, 2025.https://arxiv.org/abs/ 2503.18813 [8] Y. Ruan, H. Dong, A. Wang, S. Pitis, Y. Zhou, J. Ba, Y. Dubois, C. J. Maddison, and T. Hashimoto. Identifying the Risks of LM Agents with an LM-Emulated Sandbox. In Int. Conf. on Learning Representations (ICLR), 2024. arXiv:2309.15817. [9]E. Debenedetti, J. Zhang, M. Balunovi Ě c, L. Beurer-Kellner, M. Fischer, and F. Tramèr. AgentDojo: A Dynamic Environment to Evaluate Prompt Injection Attacks and Defenses for LLM Agents. In NeurIPS 2024 Track on Datasets and Benchmarks, 2024. arXiv:2406.13352. [10]Q. Zhan, Z. Liang, Z. Ying, and D. Kang. InjecAgent: Benchmarking Indirect Prompt Injections in Tool-Integrated Large Language Model Agents. In Findings of the ACL 2024, p. 10471â10506, 2024.https: //aclanthology.org/2024.findings-acl.624/ [11]R. Fang, R. Bindu, A. Gupta, Q. Zhan, and D. Kang. LLM Agents can Autonomously Hack Websites. arXiv:2402.06664, 2024.https: //arxiv.org/abs/2402.06664 [12]R. Greenblatt, B. Shlegeris, K. Sachan, and F. Roger. AI Control: Improving Safety Despite Intentional Subversion. arXiv:2312.06942, 2023. https://arxiv.org/abs/2312.06942 [13]Z. Wang, Y. Gao, Y. Wang, S. Liu, H. Sun, H. Cheng, G. Shi, H. Du, and X. Li. MCPTox: A Benchmark for Tool Poisoning Attack on Real-World MCP Servers. arXiv:2508.14925, 2025.https://ar xiv.org/abs/2508.14925 [14]Z. Li, K. Li, B. Ma, M. Xu, Y. Zhang, and X. Cheng. We Urgently Need Privilege Management in MCP: A Measurement of API Usage in MCP Ecosystems. arXiv:2507.06250, 2025.https://arxiv. org/abs/2507.06250 [15]W. Zhao, J. Liu, B. Ruan, S. Li, and Z. Liang. When MCP Servers Attack: Taxonomy, Feasibility, and Mitigation. arXiv:2509.24272, 2025. https://arxiv.org/abs/2509.24272 [16]H. Guo, Y. Hao, Y. Zhang, M. Xu, P. Lv, J. Chen, and X. Cheng. A Measurement Study of Model Context Protocol Ecosystem. arXiv:2509.25292, 2025.https://arxiv.org/abs/2509. 25292 [17] N. Carlini, F. Tramèr, E. Wallace, M. Jagielski, A. Herbert-Voss, K. Lee, A. Roberts, T. Brown, D. Song, Ă. Erlingsson, A. Oprea, and C. Raffel. Extracting Training Data from Large Language Models. In 30th USENIX Security Symposium, p. 2633â2650, 2021. [18] N. Carlini, C. Liu, Ă. Erlingsson, J. Kos, and D. Song. The Secret Sharer: Evaluating and Testing Unintended Memorization in Neural Networks. In 28th USENIX Security Symposium, p. 267â284, 2019. [19]M. Nasr, N. Carlini, J. Hayase, M. Jagielski, A. F. Cooper, D. Ip- polito, C. A. Choquette-Choo, E. Wallace, F. Tramèr, and K. Lee. Scalable Extraction of Training Data from (Production) Language Models. arXiv:2311.17035, 2023.https://arxiv.org/abs/ 2311.17035 [20]R. Shokri, M. Stronati, C. Song, and V. Shmatikov. Membership In- ference Attacks against Machine Learning Models. In 2017 IEEE Symposium on Security and Privacy, p. 3â18, 2017. [21] H. Pearce, B. Ahmad, B. Tan, B. Dolan-Gavitt, and R. Karri. Asleep at the Keyboard? Assessing the Security of GitHub Copilotâs Code Con- tributions. In 2022 IEEE Symposium on Security and Privacy, 2022. https://doi.org/10.1109/SP46214.2022.9833571 [22] N. Carlini, M. Jagielski, C. A. Choquette-Choo, D. Paleka, W. Pearce, H. Anderson, A. Terzis, K. Thomas, and F. Tramèr. Poisoning Web- Scale Training Datasets is Practical. arXiv:2302.10149, 2023.https: //arxiv.org/abs/2302.10149 API Secrets Should Never Become Tokens in the LLMâs Vocabulary7 [23]M. Meli, M. R. McNiece, and B. Reaves. How Bad Can It Git? Characterizing Secret Leakage in Public GitHub Repositories. In Network and Distributed System Security Symposium (NDSS), 2019. https://doi.org/10.14722/ndss.2019.23418 [24] GitGuardian. The State of Secrets Sprawl 2025. March 2025.https: //w.gitguardian.com/state-of-secrets-sprawl- report-2025 [25] D. Fett, R. KĂźsters, and G. Schmitz. A Comprehensive Formal Security Analysis of OAuth 2.0. In Proc. 2016 ACM SIGSAC Conf. on Computer and Communications Security (CCS â16), p. 1204â1215, 2016.ht tps://doi.org/10.1145/2976749.2978385 [26]J. H. Saltzer and M. D. Schroeder. The Protection of Information in Computer Systems. Proceedings of the IEEE, 63(9):1278â1308, 1975. https://doi.org/10.1109/PROC.1975.9939 [27]N. Hardy. The Confused Deputy (or why capabilities might have been invented). ACM SIGOPS Operating Systems Review, 22(4):36â38, 1988. https://doi.org/10.1145/54289.871709 [28] S. Rose, O. Borchert, S. Mitchell, and S. Connelly. Zero Trust Archi- tecture. NIST Special Publication 800-207, August 2020.https: //doi.org/10.6028/NIST.SP.800-207 [29]National Institute of Standards and Technology. Artificial Intelligence Risk Management Framework: Generative Artificial Intelligence Pro- file. NIST AI 600-1, July 2024.https://doi.org/10.6028/ NIST.AI.600-1 [30]National Institute of Standards and Technology. Adversarial Machine Learning: A Taxonomy and Terminology of Attacks and Mitigations. NIST AI 100-2e2025, 2025.https://doi.org/10.6028/ NIST.AI.100-2e2025 [31]OWASP GenAI Security Project. LLM02:2025 Sensitive Information Disclosure. OWASP Top 10 for LLM Applications 2025.https: //genai.owasp.org/llmrisk/llm022025-sensitive- information-disclosure/ [32]OWASP GenAI Security Project. LLM06:2025 Excessive Agency. OWASP Top 10 for LLM Applications 2025.https://genai. owasp.org/llmrisk/llm062025-excessive-agency/ [33] OWASP GenAI Security Project. LLM07:2025 System Prompt Leak- age. OWASP Top 10 for LLM Applications 2025.https://owas p.org/w-project-top-10-for-large-language-m odel-applications/ [34]OWASP Foundation. MCP01:2025 Token Mismanagement and Secret Exposure. OWASP MCP Top 10.https://owasp.org/w-pr oject-mcp-top-10/ [35]MITRE. ATLAS: Adversarial Threat Landscape for Artificial- Intelligence Systems. https://atlas.mitre.org/ [36]Hugging Face. Update on Spaces Secrets Incident. 1 June 2024.http s://huggingface.co/blog/space-secrets-disclo sure [37]Corvic AI. Controlled experiments E1 and E2 against Corvic Security Vault, executed 27 September 2026 (UTC). Reported results contain no secret values.