Secrets in Software and Cryptography

• Secrets are credentials or cryptographic materials that govern access, defined in both software security and formal secret-sharing schemes.
• Research highlights leakage risks in code repositories and unstructured documents, emphasizing the need for context-aware detection and effective remediation.
• Innovative protocols in agentic systems and secret sharing are redefining authorized delegation, secure computations, and resistance to exposure.

Searching arXiv for recent and foundational papers on secrets in software/security and secret-sharing to ground the article. arXiv search query: "secret leakage source code repositories (Krause et al., 2022) SUDP Secret Scanner Agent secret sharing" In contemporary computing and cryptography, a secret denotes either authority-bearing material—such as API keys, passwords, tokens, private cryptographic keys, certificates, and connection strings—or protected information that is encoded, shared, or transformed so that only authorized parties can use or reconstruct it. Recent work treats secrecy as a multi-layered problem spanning accidental disclosure in repositories and issue trackers, extraction from unstructured documents, delegation in agentic systems, threshold reconstruction, quantum protocols, and secure analytics on secret-shared data (Krause et al., 2022, Yu et al., 27 Apr 2026, Bartusek et al., 2024).

1. Technical scope and core meanings

Within software and infrastructure practice, a secret is a credential or authentication material granting access. Unstructured-document extraction work defines a secret as “a credential or authentication material granting access,” with examples including passwords, API keys, access tokens, private keys, SAS tokens, and connection strings; the same line of work defines the associated “door” as the specific entity a secret can unlock, such as an account, tenant, endpoint, database host, bucket, or internal service (Chen et al., 10 Jul 2026). Repository-leakage research uses a closely aligned typology: API keys, passwords, tokens, private cryptographic keys, and certificates are treated as code secrets whose publication can expose systems to service abuse, data breaches, privilege escalation, denial of service, and reputational damage (Krause et al., 2022).

In cryptography, the term has a second, more formal meaning. Secret sharing studies a secret $S$ as an information object distributed across shares $S_i$ so that authorized subsets reconstruct it and unauthorized subsets learn nothing. In the on-line setting, the dealer assigns shares as participants arrive, and the complexity of a scheme is measured by

$$\text{complexity}(S)=\max_{i\in V}\frac{H(S_i)}{H(S)}.$$

This distinction matters because the operational problem of protecting credentials and the formal problem of distributing protected information are different realizations of the same confidentiality requirement (Csirmaz et al., 2014).

A third meaning appears in modern model and agent systems. Agentic-secret work formalizes reusable credentials as “authority-bearing material” and treats the central problem as enabling an untrusted autonomous requester to cause a user-authorized operation without exposing reusable authority to that requester. In that formulation, secrecy is not only storage confidentiality; it is also a boundary property governing which system components may ever handle reusable authority (Yu et al., 27 Apr 2026).

2. Leakage surfaces in software ecosystems

Version-controlled repositories are a primary leakage surface because history preservation, remotes, forks, mirrors, and caches make post hoc deletion incomplete. In a mixed-methods study of developers with survey $n=109$ and 14 semi-structured interviews, 30.3% of participants had encountered secret leakage in the past, and 87.0% agreed or strongly agreed that data protection, information security, or software security issues can arise due to leaked code secrets (Krause et al., 2022). The reported causes were practical rather than exotic: hard-coding secrets for expedience or onboarding, forgetting .gitignore rules for secret-containing files such as .env, misconfigured workflows, and “off the books” repositories outside organizational controls.

Issue trackers and unstructured operational documents introduce a different leakage geometry. Issue-report work emphasizes that log files, URLs, commit IDs, stack traces, dummy passwords, shell commands, file paths, UUIDs, and hashes create high-noise environments in which secrets are embedded among lookalike strings. Its benchmark contains 25,000 instances with only 437 true positives, illustrating an extreme class imbalance and the practical difference between “credential-like text” and usable secrets (Wahab et al., 2024). Unstructured-document work extends the scope further to emails, chat threads, tickets, incident notes, Word documents, and notes, and highlights three recurrent failure modes for conventional scanners: fragmented credentials, reformatting in natural language or pasted logs, and distant context between the secret and the resource it unlocks (Chen et al., 10 Jul 2026).

These studies converge on a common operational point. Public GitHub repositories are widely crawled, but restricted repositories are not intrinsically safe: company-hosted GitLab instances, internal sharing practices, and informal repository creation can still leak secrets to unintended audiences (Krause et al., 2022). This suggests that secrecy failures are frequently produced by ordinary development and coordination workflows rather than by specialized attack tooling.

3. Detection, prevention, and remediation

Prevention guidance in repository and issue-tracker studies is strongly procedural. Recommended practices include keeping secrets out of version control, externalizing them via environment variables or protected configuration, maintaining .gitignore hygiene, using least privilege, encrypting any secrets that must reside in a repository, and integrating scanning at pre-commit, push, and CI/CD stages (Krause et al., 2022). Teams are also advised to rely on code and secret reviews, onboarding and training, and low-adoption approaches with minimal setup and friction. The emphasis on low friction is empirical: developers reported setup time, documentation gaps, training needs, refactoring effort, and cost as major adoption barriers, and some bypassed controls when those controls were heavy.

Remediation is correspondingly rotation-centric. The repository-leakage study identifies nine remediation approaches: renew or revoke the secret; remove it from source code; clean up version-control history; retract the repository; perform server operations such as backup, pruning, and reinitialization if compromise is suspected; analyze the leak; notify concerned roles; prefer constructive systemic changes over punitive responses; and tighten access management (Krause et al., 2022). A documented misconception is that cleaning Git history alone is sufficient. Interview evidence shows that some teams cleaned history without rotating or revoking the leaked secret, even though copies may already exist in forks, caches, or mirrors.

The detection literature shows why context-aware methods have become central. For software issue reports, combining targeted preprocessing, a 761-pattern regex library, and a fine-tuned transformer raises performance from regex-only $F1=0.0341$ on raw issue bodies and $F1=0.0385$ after preprocessing to $F1=0.6347$, with $0.6309$ precision and $0.6385$ recall in the best reported configuration (Wahab et al., 2024). For unstructured exposed documents, a multi-agent large-language-model system that extracts both the secret and its associated door reports precision $\ge 96.40\%$ and recall $S_i$0 on multi-type secret detection across models, matches a regex scanner’s precision while more than tripling its recall, and exceeds thirteen security analysts on pair-level extraction while running five to seventeen times faster (Chen et al., 10 Jul 2026). The key difference is that these systems do not merely return a string; they bind the secret to the account, tenant, endpoint, database, storage resource, or service it opens.

A practical implication is that detection quality is no longer reducible to regex coverage. The operationally decisive output is a secret–door–evidence tuple that supports validation, rotation, ownership routing, and triage (Chen et al., 10 Jul 2026).

4. Agentic secret use and authorization boundaries

Agentic systems sharpen a long-standing weakness in bearer-secret interfaces: authorization by exposure. If possession of a reusable API key, OAuth bearer token, or signing key is sufficient to act, then placing that material inside a model-steerable boundary makes transient prompt injection or tool compromise a path to durable account compromise (Yu et al., 27 Apr 2026). The model-steerable boundary is defined broadly to include the LLM context, planner or scratchpad, tool scheduler, tool clients, agent-visible traces and logs, and any code path whose behavior can be steered by model outputs or attacker-controlled observations.

To formalize this problem, agentic-secret work defines Agent Secret Use (ASU). Its structural obligations are authorization verifiability (AV), operation binding (OB), replay resistance (RR), and requester non-exposure, denoted CRC (Yu et al., 27 Apr 2026). The paper then proposes a three-role Secret-Use Delegation Protocol in which a requester $S_i$1 proposes a canonical operation $S_i$2, the user $S_i$3 authorizes it with a fresh authenticator-backed grant, and a custodian $S_i$4 redeems that grant exactly once to perform the bounded use at the environment $S_i$5. The binding step is

$S_i$6

with $S_i$7 a freshness token and $S_i$8 a hash of the canonical operation (Yu et al., 27 Apr 2026).

The design constraint is explicit: agents propose operations; they do not retrieve secrets. Reusable authority never crosses the requester boundary, and the unit of delegation is one authorized use rather than the secret itself. Under the paper’s stated assumptions, the protocol satisfies authorization integrity, operation-boundedness, and single-use redemption, while storage confidentiality and wrapping-epoch key isolation depend on sealing and erasure assumptions; authority-level forward secrecy additionally requires environment-side rotation and revocation (Yu et al., 27 Apr 2026).

This protocol view reframes secret management. Secret storage, scoped delegation, sender-constrained tokens, monitoring, and sandboxing remain relevant, but the paper argues that they solve adjacent pieces unless they also prevent reusable authority from entering the model-steerable boundary. In that sense, secrecy in agentic systems becomes a protocol invariant rather than a storage feature.

5. Secret sharing, threshold reconstruction, and secret-shared computation

Secret sharing provides the most formal treatment of secrecy in the supplied literature. In perfect threshold and access-structure schemes, authorized subsets reconstruct the secret and unauthorized subsets obtain no information. The on-line variant makes share assignment irrevocable as participants arrive; its general first-fit construction has complexity bounded by the maximal degree $S_i$9, yet the on-line complexity is always strictly less than $$\text{complexity}(S)=\max_{i\in V}\frac{H(S_i)}{H(S)}.$$0 for graphs, and the gap between on-line and off-line complexity can be arbitrarily large even for graph-based access structures (Csirmaz et al., 2014).

Communication and share-size efficiency lead to different optimization criteria. Communication-efficient secret sharing proves a tight lower bound on decoding bandwidth,

$$\text{complexity}(S)=\max_{i\in V}\frac{H(S_i)}{H(S)}.$$1

and gives constructions that achieve the bound universally for all $$\text{complexity}(S)=\max_{i\in V}\frac{H(S_i)}{H(S)}.$$2 in the threshold setting (Huang et al., 2015). For binary shares, classical ramp impossibility at small gap ratios can be bypassed by relaxing to semantic security and negligible reconstruction error: explicit non-adaptive schemes achieve secret length $$\text{complexity}(S)=\max_{i\in V}\frac{H(S_i)}{H(S)}.$$3, which is optimal, and adaptive schemes achieve $$\text{complexity}(S)=\max_{i\in V}\frac{H(S_i)}{H(S)}.$$4 (Lin et al., 2018). For computational threshold sharing, the PETS construction attains per-share size

$$\text{complexity}(S)=\max_{i\in V}\frac{H(S_i)}{H(S)}.$$5

and the paper proves this is optimal under non-compressibility of pseudorandom encryption and non-redundancy of the secret key (Aureliano et al., 4 Feb 2025).

Quantum variants add stronger long-term or access-structure properties. Secret sharing with certified deletion introduces quantum shares that can be verifiably destroyed, establishing no-signaling certified deletion for any monotone access structure and adaptive certified deletion for threshold schemes (Bartusek et al., 2024). Computational quantum secret sharing uses a compiler from classical secret sharing and quantum erasure-correcting codes to obtain efficient schemes for heavy monotone functions under post-quantum assumptions, and also derives improved perfect share-size bounds for a large class of access structures (Çakan et al., 2023). A threshold modulo-$$\text{complexity}(S)=\max_{i\in V}\frac{H(S_i)}{H(S)}.$$6 quantum secret-sharing protocol repairs a flaw identified by Kao et al. in Song et al.’s reconstruction method by applying the inverse quantum Fourier transform to all $$\text{complexity}(S)=\max_{i\in V}\frac{H(S_i)}{H(S)}.$$7 entangled qudits and reconstructing the secret as the modular sum of the measurement outcomes (Sutradhar, 16 Jan 2025). Polar-code constructions, finally, tie access structures to linear spans and dual-code minimal codewords, using reliable synthetic channels and Bhattacharyya-parameter ordering to realize threshold or weighted coalitions over noisy links (Moradi, 2017).

Variant	Result	Paper
On-line secret sharing	First-fit has complexity $$\text{complexity}(S)=\max_{i\in V}\frac{H(S_i)}{H(S)}.$$8; on-line complexity is always strictly less than $$\text{complexity}(S)=\max_{i\in V}\frac{H(S_i)}{H(S)}.$$9 for graphs	(Csirmaz et al., 2014)
Binary-share secret sharing	Non-adaptive rate $n=109$0; adaptive rate $n=109$1	(Lin et al., 2018)
Communication-efficient sharing	Tight lower bound $n=109$2, achieved universally	(Huang et al., 2015)
Optimal computational threshold sharing	Share size $n=109$3, proven optimal under stated assumptions	(Aureliano et al., 4 Feb 2025)
Certified deletion	NS-CD for monotone access structures; adaptive threshold A-CD	(Bartusek et al., 2024)
Computational quantum secret sharing	Efficient schemes via classical SS + QECC compiler under post-quantum assumptions	(Çakan et al., 2023)

Secret sharing also underlies secure computation systems. A relational MPC framework built on replicated secret sharing compiles SQL-like queries into oblivious operator pipelines and evaluates them over secret-shared data while revealing only the final result to a designated analyst; with logical, physical, and protocol-specific optimizations, its experiments report over $n=109$4 lower execution times than baseline approaches and million-row MPC queries with a single thread per party (Liagouris et al., 2021). Here secrecy is not a terminal property of stored shares but the operating principle of the entire query plan.

6. Protected models, latent secrets, and open problems

Secrets are not confined to credentials or shared payloads; they also appear as protected transformations and latent internal knowledge. For semantic segmentation with SETR, a post-training access-control method encrypts the patch embedding matrix as $n=109$5 and requires authorized users to apply the inverse transform $n=109$6 patch-wise to test images, so that the token sequence entering the transformer is exactly preserved for the correct key (Nagamori et al., 2022). The reported authorized accuracy matches baseline mIoU exactly, while incorrect keys cause severe degradation: for example, on Cityscapes with the PUP decoder, baseline and correct-key mIoU are both $n=109$7, whereas an incorrect key yields $n=109$8; on ADE20K with the MLA decoder, baseline and correct-key mIoU are both $n=109$9, whereas an incorrect key yields $F1=0.0341$0 (Nagamori et al., 2022).

LLMs introduce a different category: secret elicitation, defined as discovering knowledge that a model possesses and uses while denying it when asked directly. Three model families were trained to internalize a taboo word, a Base64-encoded side constraint, or a latent user gender while refusing direct disclosure. In that benchmark, black-box prefill attacks were the most effective techniques in two of the three settings, achieving $F1=0.0341$1 success in the Secret Side Constraint and User Gender settings, whereas white-box methods based on logit lens and sparse autoencoders were strongest in the remaining setting (Cywiński et al., 1 Oct 2025). The result is notable because the secret is neither stored as an explicit credential nor shared as a cryptographic payload; it is latent state shaping downstream behavior.

Across the supplied literature, open problems recur in three forms. Operationally, repository-leakage and issue-tracker studies call for better detection with fewer false positives, controlled usability studies, secure-by-default API designs, and determining the best moment for scanning and intervention—IDE, pre-commit, push, or platform (Krause et al., 2022, Wahab et al., 2024). Cryptographically, exact on-line complexities remain unknown for many access structures, adaptive certified deletion for general monotone structures is open, and further gains in quantum or communication-efficient sharing remain active topics (Csirmaz et al., 2014, Bartusek et al., 2024). For agentic systems and model auditing, the unresolved question is how to preserve useful secret-conditioned behavior while preventing either reusable authority or latent secret knowledge from being exposed across adversarial boundaries (Yu et al., 27 Apr 2026, Cywiński et al., 1 Oct 2025).

Taken together, these lines of work define secrecy as a unifying systems property rather than a single mechanism. A secret may be a credential, a threshold payload, an encrypted model transform, or latent model knowledge; in each case, the technical problem is to preserve authorized use while making exposure, misuse, or unauthorized reconstruction structurally difficult.