Executive briefEvery new automation inherited the same old secret

A platform inventory found thousands of agents, bots and services using a smaller collection of shared API keys and service-account passwords. Some secrets were copied across development and production. Others appeared in deployment variables, notebooks and debugging tickets. Rotation dates existed, but consumer lists did not. Revoking one key risked stopping unrelated workflows; leaving it active preserved an exposure window no one could define.

Automation had multiplied faster than identity operations. Teams created friendly agent names, then attached standing credentials designed for long-lived applications. A key proved possession, not which runtime used it, which principal supplied the mandate or whether the current task still existed. Paused tasks retained refresh capability. Peer agents forwarded bearer tokens. The organisation gained more non-human workers while losing selective attribution and containment.

The preferred direction is secretless at the workload. The platform attests the running process, assigns a workload identity and lets a broker exchange current identity and mandate for a narrow credential. The credential expires quickly, is accepted only by its intended resource and is bound to the workload or its key. The upstream user's refresh token, reusable API key or service password never enters model context.

Secretless does not mean no sensitive key material exists anywhere. Trust anchors, issuer keys, workload keys, bootstrap mechanisms, brokers and recovery secrets remain. They move into controlled infrastructure with explicit lifecycle and smaller exposure. Legacy resources may still require a password or key. The honest architecture combines workload identity where supported with rigorous, recoverable secret handling where it is not.

This paper proposes a fourteen-field Non-Human Credential Record, an eight-step Secretless Credential Path, a Credential Exposure Ledger and an Orphan Test. They turn credential hygiene from periodic rotation into an operating system for issuance, use, exposure, recovery and retirement.

The strongest rival: managed static secrets can be safer

A disciplined secrets service with named owners, short rotation, protected delivery and tested cutover can be simpler and safer than a poorly deployed workload-identity fabric. Attestation errors can grant the wrong identity. Broker or certificate-authority failure can lock out critical services. Trust-domain configuration and issuer compromise concentrate risk.

The choice is not fashion. Use short-lived workload credentials where platform identity is reliable and the resource can enforce them. Retain managed static credentials at unavoidable boundaries with transparent exposure and dependency records. Do not describe migration as finished until recovery, issuer compromise, broker outage and rotation failure have been exercised.

Non-Human Credential RecordFourteen fields join identity, material, use and retirement

The record can be assembled from identity, secrets, certificate, deployment, policy and resource telemetry systems. A single catalogue is useful, but the underlying writers remain authoritative. Rotation frequency copied into a spreadsheet is not evidence that every consumer moved. A recent login is not evidence of justified use. The record links the claim to receipts.

Credential class determines the threat. A bearer API key can be replayed by any holder. A private signing key may allow durable impersonation. A bound short-lived token reduces replay but can still be too broad. A recovery secret is intentionally exceptional and therefore needs stronger custody. Treating all of these as “secrets” hides the lifecycle controls that differ.

Secretless Credential PathAttest, exchange, bind, enforce, receipt and expire

Platform attestation establishes facts about the running workload through a protected local mechanism. Workload identity gives the process a cryptographic subject in a trust domain. SPIFFE's Workload API is one platform-neutral pattern for delivering identity documents and propagating updates, but the implementation must reliably identify the local caller.

Policy and mandate checking joins workload subject to business owner, active task, resource, purpose and limits. Token exchange produces a downstream credential whose authority is no greater than that intersection. Actor and subject remain distinguishable. The workload does not receive a user's refresh token and cannot choose a larger audience because a prompt requests it.

Short-lived audience and proof binding constrains where and by whom the credential can be used. OAuth resource indicators, mutual TLS and proof-of-possession mechanisms offer relevant patterns. The resource still validates tenant, method, business purpose, transaction and live state. A cryptographically valid token can be denied.

Resource enforcement makes the decision independently of model text. Use receipt records subject, case, action, result and anomaly without storing full tokens or private keys. Expiry closes the path. If a task resumes after expiry, current mandate and state are checked again. Automatic renewal beyond the original task duration would recreate standing authority.

Short lifetime is not a substitute for narrow authority. A five-minute token that can read every tenant, export all fields or initiate unrestricted transactions may cause its full harm in seconds. Issuance therefore evaluates audience, resource, method, data, transaction and delegation before considering expiry. Red teams test the maximum action possible during the valid window, including parallel calls and rapid automation. If that effect is unacceptable, the broker denies exchange or issues a more restricted credential even when attestation, signature and proof binding are perfect.

Issuer and broker compromise remain critical scenarios. Trust roots need protected keys, rotation, separation, distribution and recovery. Broker policy has tests and independent deployment controls. Workloads define behaviour when identity updates stop. Short credential life can limit exposure but can also create broad outages when issuers fail; continuity is designed alongside security.

Unavoidable secretsLegacy credentials need a justified path, not an exception label

A database or vendor API may accept only a password or static key. The credential remains in a managed store and is delivered through a broker or sidecar to the smallest possible runtime boundary. Access to the store does not automatically expose every secret. Delivery avoids prompt templates, generated code, command history and shared environment dumps. The workload sees the secret only if the protocol makes that unavoidable.

Encryption at rest is necessary but incomplete. A secret must be decrypted for use; the decisive risks appear in delivery, process memory, logs, backups, crash dumps and consumers. Environment variables can be inherited, inspected or accidentally recorded. File mounts can persist. The record states every plaintext or bearer exposure and its maximum lifetime.

Rotation is a dependency change. Before issue, teams know all consumers, versions, caches, replicas, fallback paths and owner contacts. They test dual-read or overlap behaviour where supported. Cutover evidence shows new credential use at each consumer and absence of old use. Only then is the old credential revoked. The overlap window is short and explicit because two valid secrets increase exposure.

Recovery does not mean keeping an undocumented permanent master password. Emergency material has split or dual control, narrow scope, issue approval, short expiry and retrospective review. The recovery path is exercised without placing the credential in runbooks or tickets. If a legacy boundary cannot support rotation, selective revoke or safe recovery, its risk is visible and migration has an owner.

Credential Exposure LedgerMap every place a credential can become content

A prompt or model context is not a secret store. A token placed there can be reproduced in output, retained in traces, sent to a provider or revealed through tool calls. Tool descriptions and generated code are also content channels. The design supplies opaque action handles or brokered execution rather than credential strings.

Observability is a frequent exposure route. Full authorisation headers, query-string keys, private certificates and environment snapshots do not belong in logs. Redaction happens before emission, with tests for common encodings and structured fields. Access to traces and dumps is narrower than general developer access, retention is short and exports are controlled. Detection searches historical stores because a newly discovered leak may predate the alert.

The Exposure Ledger records path, asset, environment, owner, prevention, detector, first and last possible exposure, credential lifetime, affected consumers, resource use and response receipt. Absence of observed misuse is not proof of safety when logging coverage or resource receipts are weak. The review window covers all actions that the credential could have authorised.

Build systems, notebooks and support processes need the same scrutiny. A secret embedded in an image layer survives deletion from a later layer. A notebook output can remain after the cell is cleared. A screenshot can escape automated scanners. A support ticket may be copied to another system. SLSA provenance helps trace build artefacts and their production, but it does not prove that credential material was absent; dedicated scanning and build isolation remain necessary.

Rotation and exposure responseChange material, contain use and reconcile effects

When a trace captures an authorisation header, responders revoke or disable the credential, quarantine the workload and stop new exchange. They identify equivalent or derived credentials, cached sessions and downstream tokens. They preserve the relevant trace under restricted access while removing avoidable copies. Rotation supplies new material only to verified consumers.

The affected-action review spans from first possible exposure to effective revocation, not merely from alert time. Resource receipts reveal methods, cases, locations, volumes and outcomes. Suspicious actions are contained and reconciled. Customers or counterparties are identified where correction or notice may be required. The incident closes only when use, residual access and business effects are understood.

Rotation failure reveals operational truth. If an unknown consumer breaks, teams do not silently reactivate the old secret indefinitely. They enter a controlled overlap or recovery path, identify the workload and owner, test its purpose and add the dependency record. A consumer that cannot be justified may be an orphan or unauthorised copy rather than a reason to preserve exposure.

Emergency issuance is separate. Two authorised people approve the exact resource and duration, the credential is delivered through the protected path, every use is receipted and expiry is automatic. Retrospective review confirms why normal identity failed, what changed and whether the emergency path introduced new copies.

Orphan TestRenewal is earned by current evidence

An active credential can be ownerless even while traffic continues. Scheduled jobs, copied scripts and forgotten integrations can create use without accountability. The Orphan Test asks whether an active owner, approved workload, recent justified use, reachable dependency, tested rotation and retirement date exist. Missing evidence denies automatic renewal and opens an investigation.

The investigation separates an undocumented legitimate dependency from a hostile or obsolete consumer. Resource logs, deployment records, network identity, code ownership and action receipts help identify the path. Temporary continuation, if necessary for safety or continuity, uses time-limited approval and narrower authority. It does not become a new permanent exception.

Retirement first disables issuance and exchange, then observes for failed dependencies. Reusable material is revoked, replicas and backups follow retention policy, bindings and accounts are removed, and remaining business effects are reconciled. Evidence needed for audit is archived without preserving an active secret. Owner attestation closes the record.

Deletion before dependency analysis can destroy a recovery route or create an outage. Conversely, fear of outage cannot justify perpetual renewal. The test turns ambiguity into a controlled decision with a deadline, owner and receipt.

Ten worked casesIssue, expose, rotate, recover and retire

1. Internal agent replaces a key

A supported compute platform attests the agent process and delivers a workload identity. Policy exchanges it for a ten-minute token to one internal API. No API key remains in deployment variables. Resource receipts join the task and subject. Outcome: replace the stored secret with platform workload identity.

2. Scheduled bot

The scheduler attests the job at each run. The broker checks the current service mandate and issues a resource-specific token that cannot reach other environments. The job cannot refresh after its run window. Outcome: broker a short-lived audience-bound credential.

3. User-delegated agent

The agent receives a token for one case and preparation method through exchange. The user's refresh token remains with the identity service. Pause or user-session revocation prevents renewal. A short-lived token proposing broad customer access is still denied because scope, not only time, is wrong. Outcome: exchange the principal mandate for a transaction-scoped token.

4. Legacy database password

A broker retrieves the database password and injects it into a sidecar for the named workload. Consumers, replicas, rotation overlap and fallback are tested. Queries and case purpose are separately enforced because the password remains broad. Outcome: broker a short-lived audience-bound credential around the justified legacy boundary.

5. Paused long-running task

The token expires while the task waits. On resume, workload identity is current but the business case has changed. Exchange revalidates mandate and state rather than renewing from the old token. The action is denied until the owner issues a fresh task decision. Outcome: exchange the principal mandate for a transaction-scoped token.

6. Peer-agent token forwarding

A planner passes its bearer token to a worker. The resource rejects the worker because audience and proof binding do not match. Proper delegation issues a new, narrower credential to the worker if the subtask is authorised. Outcome: broker a short-lived audience-bound credential.

7. Header in a debugging trace

A trace captures a full authorisation header. Detection revokes the token family, quarantines the workload, scans related stores and reviews all resource actions during the exposure window. New credentials are issued only after the instrumentation is repaired. Outcome: rotate, revoke and quarantine after credential exposure.

8. Rotation breaks an unknown consumer

Old-secret use continues from an unidentified host after planned cutover. The team uses a controlled overlap while identifying the process, owner and business purpose. It does not make the old credential permanent. The dependency map and recovery test are corrected before final revoke. Outcome: rotate, revoke and quarantine after credential exposure.

9. Emergency credential

A production recovery requires temporary database access. Two people approve a restricted credential for one hour. Delivery is protected, use is receipted and expiry is automatic. Retrospective review links the break-glass event to the failed normal path. Outcome: exchange the principal mandate for a transaction-scoped token.

10. Orphaned account

A non-human account has no active owner, approved workload or recent justified use, and its rotation test fails. Renewal stops. Investigators map remaining dependencies, preserve necessary audit evidence, disable the account and remove reusable material after a safe observation window. Outcome: disable the orphaned or ungovernable non-human identity.

Interactive decision artefactNon-Human Credential Lifecycle Gate

The gate selects one lifecycle path and names the broken edge. It does not return a hygiene score, secret-count target or renewal based solely on prior possession.

Operating cadenceRun credential hygiene as continuous identity operations

At onboarding, teams create the fourteen-field record, prefer platform identity, define trust domain, purpose, authority, exposure paths, use receipts, recovery and retirement. Legacy secrets require a migration owner and tested consumer map.

At issuance, platform attestation and current business mandate drive exchange. Audience, lifetime and proof binding are narrower than the upstream authority. Paused tasks and changed state require a fresh decision. Issuer and broker health have explicit fail-safe behaviour.

During use, resources write action receipts while telemetry excludes credential material. Teams monitor unusual audience, location, method, rate, renewal, failed binding, old-secret use and new exposure copies. Scanners cover prompts, logs, builds, notebooks and support systems.

At rotation, every consumer proves cutover within the overlap window. Unknown use creates a dependency investigation, not an indefinite exception. Recovery and emergency credentials remain narrowly scoped, dual-controlled and automatically expiring.

On exposure, revoke, quarantine, rotate, invalidate downstream credentials and review all possible actions. Technical credential replacement does not close the incident until business effects are reconciled. Evidence is preserved without maintaining active secret copies.

At renewal and retirement, the Orphan Test demands current owner, workload, use, dependency, rotation and end date. Failed checks stop automatic renewal. Controlled disablement, observation, removal and owner attestation close the identity.