Identity Propagation Closes the Attribution Gap on AI-Generated Passwords

On May 8, 2026, GitGuardian published The Bot Left a Fingerprint. The team trained per-model Markov chains on password outputs from frontier providers and applied a 75% confidence threshold to classify new passwords. Run against 34 million passwords observed on public GitHub between November 2025 and March 2026, the classifier identified 28,000 as LLM-generated. The chains assign the right model in 55% of cases and the right provider in 65%.

The research closes detection. Attribution stays open. A leaked credential labeled "Claude-generated" or "Qwen-generated" is the start of the forensic chain. The questions that follow are operational: which authenticated user issued the prompt, on whose behalf, under what role, on what date. Those answers live in the AI traffic that produced the credential.

How the bias detection works

The mechanism is a per-model Markov chain trained on password outputs from each frontier provider. A new password is scored against each chain. The model whose chain assigns probability above the 75% threshold is the predicted source. The research surfaces uniqueness as the differentiating signal. Claude Opus 4.6 produced unique outputs in only 35% of generations in the sample. Qwen, Llama, and Gemma fell between 50% and 60%. The GPT-5 family produced 100% unique outputs.

That uniqueness gap is what makes attribution possible. A model that repeats subtle character distributions across generations leaves a statistical fingerprint. The fingerprint survives token boundary differences and length variation. Deliberate post-processing erases it. Credentials committed directly to repositories typically arrive with the fingerprint intact, because most copy-and-paste flows preserve the output verbatim.

The attribution gap

A leaked credential identified as AI-generated produces three immediate questions. Which authenticated user issued the prompt that generated it. Which model returned it. Whether other credentials from the same user, same model, same period are also at risk. The AI traffic logs hold those answers, when the logs captured identity at the boundary the call traversed.

Most LLM gateways today log the model and the request id. Fewer propagate the originating directory identity into the audit record, because the gateway's own service token replaces the user identity at egress to the provider. That replacement is the gap. Every model call in the audit trail looks like it came from "the gateway service account" and the attribution chain stops there. GitGuardian's classifier closes the credential side of the gap. Closing the request side requires the traffic-plane log to carry identity all the way through to the audit record.

Identity at the call boundary

The minimum log record at the AI call boundary needs six fields. Subject identity from the directory. Role at the time of the call. Model and provider. Prompt classification, with a flag for credential-generation language. Response classification, with a flag for credential-shaped output. Session id that joins every call in one logical user request, including hops across agents.

In pseudocode:

on_outbound_model_call(request):
    user = directory.resolve(request.auth_principal)
    role = directory.role_for(user)
    prompt_class = classifier.classify_prompt(request.body)
    response = forward(request, scope=role)
    response_class = classifier.classify_output(response)
    log.signed({
        session_id: request.session_id,
        user_id: user.id,
        role: role,
        model: request.model,
        provider: request.provider,
        prompt_class: prompt_class,
        response_class: response_class,
        timestamp: now(),
    })
    return response

Three properties of this record matter for forensic use. The session id is the join key for every call inside one logical user request, including hops across agents. The role at time of call captures the user's effective permissions in that moment, separately from any role changes that follow. The signature anchors the record so a downstream pipeline cannot quietly drop the user_id field on the way to the SIEM. The broader audit-trail pattern is in How to Build a Defensible AI Audit Trail.

Detection beyond logging

Logging is the floor. The call boundary can also detect-and-decide. A prompt classifier flags "generate a strong password," "create an API key," "produce a 32-character secret." On the response side, the gateway scores outputs for credential shape: entropy, character class diversity, and length within typical credential ranges. Either signal raises a policy decision.

The decision tree:

if prompt_class.is_credential_request:
    if user.role.allows_llm_credential_generation:
        annotate_response(redirect_to=secrets_manager_doc)
    else:
        deny(reason="credentials must come from secrets manager")

The mechanism is a policy decision at the gateway, evaluated against the policy bound to the user's role. A permitted decision forwards the response with an annotation pointing to the corporate secrets manager. Denial returns the same pointer as the reason, with the credential held at the gateway. Both decisions land in the audit trail with full identity context. The attribution question becomes answerable before the credential ever reaches a commit.

The scope of enforcement

The call boundary catches what passes through it. A developer who calls a frontier model from a personal account on a personal device sits outside the scope. The mechanism that closes that gap is egress control plus vendor-account discipline: corporate networks block direct LLM API egress except through the gateway, vendor accounts are bound to corporate SSO, and personal-account access falls outside corporate-funded provisioning. None of this is novel. Security teams have run the same shadow-IT pattern against SaaS for a decade.

What is new on May 8, 2026 is the cost of the unmonitored path. A leaked credential in a corporate repo, classified as AI-generated, with no corresponding AI traffic log, lands as a finding in two evidence categories: secrets sprawl and audit gap. Both surface in the same audit-trail review at HHS OCR for HIPAA exposures, the FTC under Section 5 for broader breach reporting, or sector regulators such as the OCC. The audit gap is harder to remediate after the fact than the leaked secret itself.

A four-step audit

If I were a CISO reading the GitGuardian post on Monday morning, I would do four things.

1. Apply GitGuardian's published methodology to credentials your secrets scanner flagged in the last six months. Anything labeled AI-generated becomes the seed for an attribution audit.

2. For each AI-generated credential, attempt attribution from your existing AI traffic logs. Identify the originating user, the model, the prompt. The percentage you can attribute is the inverse of your attribution gap.

3. For unattributable credentials, identify which gateway path produced them and how that path handles identity. Service-token-only paths are the next remediation target.

4. Add credential-request prompt classification to the policy plane. The annotate-or-deny decision based on role is a one-week build for any team already running a gateway.

These four steps tell you which AI-generated credentials in your environment you can attribute today, and where the gap is.

DeepInspect

DeepInspect is an identity-aware enforcement plane on AI traffic. The six log fields above are produced per call as a signed evidence record. The credential-request prompt classifier runs at the boundary. The role-based decision pattern (annotate-and-redirect or deny) lands in the same audit trail.

The honest scope: DeepInspect inspects the AI traffic that traverses it. A developer calling a model from a personal account on a personal device sits outside the scope. Closing that gap is an egress and procurement control problem, separate from enforcement-plane work. The combination produces a complete attribution chain.

For GitGuardian-style findings, the practical effect is that AI-generated credentials produced through the corporate path arrive in the audit trail with identity attached. The chain ends at a known user, role, and prompt, instead of at "the gateway service account."

Common questions

How did GitGuardian identify AI-generated passwords?

GitGuardian trained Markov chains on password outputs from specific frontier models, then scored 34 million passwords observed on public GitHub between November 2025 and March 2026. A password is classified as LLM-generated when a model-specific chain predicts it with probability above 75%. The May 8, 2026 research reports 28,000 credentials classified as AI-generated. The chains identify the correct model in 55% of cases and the correct provider in 65%. The mechanism rests on uniqueness: Claude Opus 4.6 produced unique outputs in only 35% of generations in the sample, while the GPT-5 family produced 100%. Models that repeat subtle character distributions across generations leave a statistical fingerprint that survives token boundary differences and length variation. Deliberate post-processing erases the fingerprint. Credentials committed directly to repositories typically arrive with the fingerprint intact.

What additional evidence do you need beyond the AI-generated label?

GitGuardian's label tells you which model produced a leaked credential, with model attribution at 55% accuracy and provider attribution at 65%. Four operational questions remain open: which authenticated user issued the prompt, on whose behalf, under what role, on what date. Those answers live in the AI traffic logs that captured each model call at the boundary it traversed. Most LLM gateways log the model and request id today. Fewer log the originating directory identity, because the gateway's service token replaces the user identity at egress to the provider. That replacement is the attribution gap. Closing it requires the gateway to propagate the user's directory identity into the audit record, indexed by a session id that survives across any agent hops in the call chain.

How do you classify a credential-generation prompt at the boundary?

A prompt classifier scans for two signal types. Direct credential requests use language like "generate a password," "create an API key," "produce a 32-character secret," "make a random token." A keyword classifier with a small set of regular expressions catches the obvious cases. Obfuscated requests, where the user asks for a "random string" without specifying purpose, are harder. For those, a response classifier examines the model output for credential-shaped properties: high entropy, character class diversity, length within typical password ranges. Either signal raises the policy decision. Both classifiers are local to the gateway, run on the prompt and response in transit, and contribute to the audit record with negligible latency impact. The classifier is intentionally narrow; the goal is policy enforcement at credential-shaped intent, separate from content filtering at scale.

What does role-based enforcement look like for credential generation?

Roles in the corporate directory map to permitted behaviors at the AI call boundary. A platform engineer's role might permit LLM-based credential generation with an annotation directing the response to the corporate secrets manager. A general engineering role might deny the request with a pointer to the same secrets manager. A security operator's role might permit generation in a sandbox environment for testing. Each decision lands in the audit trail with the originating user, the role, the prompt, the response classification, and the policy version. The pattern is identical to least-privilege role assignment in any access control system. The novelty is the place where the decision is evaluated: at the model call boundary, before the response leaves the gateway. This is the same boundary where SR 11-7 model risk management documentation, HIPAA 45 CFR 164.312(b) audit controls, and EU AI Act Article 12 record-keeping apply.

What egress controls support AI credential policy?

Three controls work together. Network egress rules block direct API access to known LLM provider endpoints from corporate networks except through the gateway. SSO-bound vendor accounts ensure corporate model usage is provisioned through a single identity authority. Procurement controls flag personal credit card payments to LLM vendors during reimbursement review. Each control closes one path around the gateway. The combination ensures that any AI-generated credential produced inside the corporate path is attributable through the gateway's audit trail. Residual shadow LLM use persists, the same problem security teams have managed for SaaS for a decade. The new factor on May 8, 2026 is that GitGuardian's research provides external attribution at the leak point, which means the cost of an unmonitored path lands directly in SEC Item 1.05 Form 8-K cybersecurity disclosure reviews and HHS OCR breach notification correspondence.

What HIPAA, SR 11-7, or EU AI Act obligations apply to AI-generated credential audits?

HIPAA 45 CFR 164.312(b) requires audit controls capable of recording and examining activity in systems containing protected health information. An LLM-generated credential that grants access to PHI systems falls under this audit requirement, including the identity that requested it. SR 11-7 model risk management requires documentation of model usage, including effective challenge processes for outputs that materially affect operations. Credential generation that ends up in production qualifies. EU AI Act Article 12 requires automatic recording of events for high-risk AI systems sufficient to enable post-market monitoring. An AI-generated credential producing access into a high-risk system carries the Article 12 logging obligation. In each regime the practical implication is identical: the audit record must include the originating user identity at the time of the model call. A gateway that logs only the service token fails all three regimes.

What is the difference between a content filter and a policy decision at the call boundary?

A content filter operates on the model output and may suppress or alter the response. A policy decision at the call boundary works one layer earlier. It evaluates the request against role, declared purpose, and data class, then chooses among forward, deny, annotate, or redirect. The two land differently in the audit record. A filter notes only that a credential exists in the response. The decision captures the full evaluation context: role, declared purpose, evaluation result, and the model output as one field in the record. The forensic implications differ. A filter-only audit produces a censored response without context. The policy-decision audit produces an evidence record that supports attribution and post-incident review. The two layers compose. A policy decision can route to a content filter, with the filter operating downstream of the decision.

How does session id propagation work across agent hops?

A session id is generated at the first authenticated entry point, typically the user's browser or workstation client. Every downstream call inherits it through the request context. When an agent calls another agent or a model, the calling agent forwards the session id in a dedicated header. The receiving agent extracts the session id and writes it into its own log record before issuing its outbound calls. The result is a single join key that links every model call, every tool call, and every retrieval event back to the originating user request. A forensic reviewer pulls one query against the SIEM keyed on the session id and reconstructs the full chain in a single result set, instead of stitching it from five log sources with timestamp heuristics. Without this propagation, the chain breaks at the first agent hop.