Secrets Scanning on Deploy Governance

2. Summary

Secrets Scanning on Deploy Governance requires that every artefact destined for deployment — container images, configuration bundles, runtime packages, model serving configurations, infrastructure-as-code templates, and environment variable manifests — is scanned for accidentally embedded secrets before it reaches any target environment. Secrets include API keys, database credentials, private keys, tokens, connection strings, service account keys, and any other authentication or authorisation material whose exposure would grant an adversary access to protected resources. The scanning must occur as a mandatory, blocking gate in the deployment pipeline: artefacts containing detected secrets are rejected before deployment, the offending secret is identified for remediation, and the exposed credential is flagged for immediate rotation via AG-012.

3. Example

Scenario A — Database Credential Embedded in Model Serving Configuration: An ML engineering team builds a model serving container that loads configuration from a YAML file baked into the container image at build time. During development, an engineer hardcodes the production database connection string — including the username and password — into the configuration file for local testing convenience. The engineer intends to replace it with an environment variable reference before committing but forgets. The container image passes functional testing (which uses the embedded credential to successfully connect to the production database) and is promoted to the production registry. An external security researcher discovers the credential by pulling the publicly accessible container image from the registry and running a standard layer inspection tool. The researcher reports the finding through a responsible disclosure programme 14 days after the image was published. During those 14 days, the database was accessible to anyone who inspected the image.

What went wrong: No secrets scanning gate existed in the build or deployment pipeline. The container image was treated as an opaque binary artefact and was not inspected for embedded credentials. The functional test suite passed because the hardcoded credential worked — the test validated the wrong thing. Consequence: 14-day exposure window for the production database containing 2.3 million customer records, mandatory breach notification under GDPR Article 33, emergency credential rotation affecting 17 dependent services (causing 4 hours of partial service disruption), regulatory inquiry, and approximately GBP 890,000 in incident response, legal, and notification costs.

Scenario B — Private Key Committed in Infrastructure-as-Code Template: A DevOps engineer generates a TLS private key for an agent's mutual-TLS communication channel and temporarily stores it in the infrastructure-as-code repository alongside the Terraform templates while testing the deployment configuration. The .gitignore file excludes *.pem files but the engineer saves the key with a .key extension, which is not excluded. The key is committed, pushed to the shared repository, and included in the deployment bundle that provisions the agent's infrastructure. The key is now embedded in the Terraform state file, the repository history, and the deployed infrastructure configuration. Six months later, an attacker who gains read access to the repository (via a compromised CI/CD service account) extracts the private key and uses it to impersonate the agent on the mutual-TLS channel, intercepting governance policy updates and injecting modified policies.

What went wrong: No secrets scanning was performed on the infrastructure-as-code repository or the deployment bundle. The .gitignore exclusion was incomplete. The private key was committed to version control and persisted in the repository history even after later deletion from the working tree. Consequence: The attacker intercepted and modified governance policy updates for approximately 90 days before detection, during which the agent operated under relaxed transaction limits. Financial exposure during the window: USD 12.7 million in transactions that exceeded the approved limits. Regulatory enforcement action by the OCC for inadequate key management and access controls.

Scenario C — Service Account Token in Agent Runtime Bundle: An organisation packages its AI agent as a runtime bundle containing the agent code, model reference, configuration, and a startup script. The startup script includes a hardcoded service account token that grants the agent access to the organisation's secret management vault — the very system that is supposed to dispense credentials securely at runtime. The token was embedded during an emergency deployment when the standard secret injection mechanism was temporarily unavailable. The emergency workaround was never reverted. The runtime bundle is deployed to 340 edge devices. When one edge device is physically compromised (stolen from a retail location), the attacker extracts the vault token from the startup script, gaining access to every secret stored in the vault — including credentials for payment processing, customer databases, and partner API integrations.

What went wrong: No secrets scanning was performed on the runtime bundle before distribution. The emergency workaround introduced a hardcoded credential that was never removed. The vault token embedded in the bundle provided access to the entire secrets management infrastructure, making a single compromised device a pivot point for the entire organisation. Consequence: Complete compromise of the organisation's secrets management infrastructure, mandatory rotation of all credentials (affecting 214 services and requiring 72 hours of coordinated remediation), payment processing downtime of 18 hours, estimated total incident cost of GBP 3.4 million including forensic investigation, credential rotation, regulatory reporting, and customer notification.

4. Requirement Statement

Scope: This dimension applies to every artefact that is deployed to, or made accessible in, any environment where AI agents operate or where governance infrastructure runs. Artefacts in scope include: container images and their constituent layers; configuration files in any format (YAML, JSON, TOML, INI, XML, HCL, and proprietary formats); infrastructure-as-code templates and associated state files; runtime bundles and packages; environment variable manifests and .env files; build output directories and compiled binaries (scanned for embedded string literals); model serving configurations; agent startup scripts and entrypoint definitions; and any archive (ZIP, TAR, OCI image) distributed through the deployment pipeline. The scope excludes secrets that are legitimately injected at runtime through an approved secret management mechanism (AG-012), as these are not embedded in the artefact. The scope includes secrets that are present in version control history — a secret that was committed and later deleted from the working tree is still exposed in the repository history and must be detected and remediated. The scanning obligation applies regardless of whether the artefact is destined for an internal or external environment; internal deployments carry equivalent risk because internal network access is routinely compromised.

4.1. A conforming system MUST scan every deployment artefact for embedded secrets before the artefact is promoted to any non-development environment, using pattern matching, entropy analysis, and known-format detection to identify API keys, database credentials, private keys, tokens, connection strings, and other authentication material.

4.2. A conforming system MUST block deployment of any artefact in which a secret is detected, returning a structured rejection that identifies the artefact, the location of the detected secret within the artefact (file path and line number or byte offset), and the secret type.

4.3. A conforming system MUST trigger a credential rotation workflow via AG-012 for any secret detected in a deployment artefact, on the assumption that the secret has been exposed and must be treated as compromised regardless of whether the artefact was actually deployed.

4.4. A conforming system MUST scan all layers of container images, not only the final layer, to detect secrets that were introduced in an intermediate build stage and subsequently deleted or overwritten in a later stage.

4.5. A conforming system MUST scan version control history for secrets when the deployment artefact is sourced from a version-controlled repository, detecting secrets that were committed in any prior commit even if they have been removed from the current working tree.

4.6. A conforming system MUST generate an immutable audit record for every scan execution, recording: the artefact identifier, the scan timestamp, the scanning tool version and rule set version, the scan result (pass or fail), and for failures, the list of detected secrets with their locations and types.

4.7. A conforming system MUST alert the security operations function within 15 minutes of detecting an embedded secret in any deployment artefact.

4.8. A conforming system SHOULD maintain an allow-list of known false positives, reviewed and re-approved at least quarterly, to prevent alert fatigue from causing genuine detections to be ignored.

4.9. A conforming system SHOULD scan artefacts in the development environment as well (pre-commit or pre-merge), providing early feedback to developers before secrets reach the deployment pipeline.

4.10. A conforming system SHOULD integrate scanning results with the build pipeline attestation record (AG-407), so that deployment approval is conditional on a passing scan result.

4.11. A conforming system MAY implement real-time monitoring of public code repositories, container registries, and paste sites for secrets that match the organisation's credential patterns, as a supplementary detection mechanism for secrets that bypass the pipeline gate.

4.12. A conforming system MAY implement automated remediation that revokes detected secrets immediately upon detection, rather than waiting for the manual credential rotation workflow.

5. Rationale

Accidental secret exposure in deployment artefacts is consistently one of the most common and consequential security failures in software and AI system operations. Industry research demonstrates the scale of the problem: studies of public repositories have found millions of secrets committed to version control, and private repositories are not immune — the same development practices that lead to public exposure occur behind the firewall with equal frequency. For AI agent deployments, the risk is amplified by several factors specific to the domain.

First, AI agent deployments involve a broader set of artefact types than traditional software. In addition to application code and container images, AI deployments include model serving configurations, fine-tuning parameter files, governance policy bundles, tool integration configurations, and infrastructure-as-code templates for GPU clusters and inference endpoints. Each of these artefact types can harbour embedded secrets, and many of them are authored by ML engineers and data scientists who may have less security training than software engineers. The configuration files for model serving frameworks frequently require database connection strings, API endpoints, and authentication tokens — and the path of least resistance during development is to embed these values directly rather than configuring secret injection.

Second, AI agent deployments often have broader access than traditional applications. An AI agent may hold credentials for payment systems, customer databases, partner APIs, governance infrastructure, and model registries simultaneously. A single exposed credential can provide a pivot point to multiple high-value systems. The vault-token scenario in Example C illustrates the worst case: a credential for the secret management infrastructure itself, which grants transitive access to every other secret.

Third, the deployment topology for AI agents is often more complex than traditional applications. Edge deployments distribute artefacts to physically insecure locations. Multi-region deployments replicate artefacts across jurisdictions. Partner integrations share artefacts with external organisations. Each distribution point is a potential exposure point, and the broader the distribution, the harder it is to contain an exposure after the fact.

The regulatory environment treats credential exposure as a failure of basic security hygiene. The EU AI Act Article 15 requires cybersecurity measures appropriate to the risk. DORA Article 9 requires financial entities to manage ICT risks, which includes credential management. The FCA expects firms to demonstrate that credentials are managed securely and that exposure is detected promptly. ISO 27001 controls A.9.2 (Access Management) and A.9.4 (System and Application Access Control) directly address credential security. PCI DSS Requirement 8 requires that authentication credentials are protected. A secret embedded in a deployment artefact is a failure against all of these frameworks simultaneously.

The cost asymmetry between prevention and remediation strongly favours pipeline-integrated scanning. Detecting a secret in a deployment artefact before it leaves the build environment is a low-cost operation: the deployment is blocked, the secret is removed, the credential is rotated, and the artefact is rebuilt. Detecting the same secret after deployment — through a breach, a researcher disclosure, or a regulatory audit — triggers incident response, forensic investigation, credential rotation across all affected systems, breach notification obligations, regulatory engagement, and potential litigation. The ratio of remediation cost to prevention cost routinely exceeds 100:1.

6. Implementation Guidance

AG-406 establishes secrets scanning as a mandatory, blocking gate in the deployment pipeline for AI agent systems. The objective is to detect accidentally embedded secrets before they reach any non-development environment, trigger remediation for any detected exposure, and maintain an auditable record that demonstrates the scanning was performed and the results were acted upon.

The scanning function should be integrated as a discrete stage in the deployment pipeline, positioned after the artefact is built and before it is promoted to any target environment (staging, production, edge, partner). The scanning stage must be mandatory — it cannot be bypassed by pipeline configuration, environment variable override, or manual approval. The pipeline must be architecturally designed so that there is no path from build to deployment that does not pass through the scanning gate.

Recommended patterns:

• Multi-technique scanning engine. Combine three complementary detection techniques: (1) pattern matching using regular expressions tuned to known secret formats (AWS access keys, GCP service account keys, GitHub tokens, database connection strings, JWT signing keys, etc.); (2) entropy analysis that identifies high-entropy strings that may be secrets even if they do not match a known pattern; and (3) known-format detection that recognises the structure of private keys (PEM headers), certificates, and serialised credential objects. The combination reduces both false negatives (secrets in non-standard formats) and false positives (high-entropy strings that are not secrets).
• Layer-aware container image scanning. Container images are composed of multiple layers, each representing a build step. A common anti-pattern is to copy a secret into an early build layer (for compilation or dependency resolution), then delete it in a later layer. The secret is absent from the final filesystem but remains in the intermediate layer, which is included in the distributed image. Scanning must decompose the image into individual layers and scan each layer independently. The same principle applies to multi-stage builds: all stages must be scanned, not only the final stage.
• Pipeline-integrated blocking gate. Implement the scanning stage as a pipeline step that produces a structured pass/fail result. A pass result is required for the pipeline to proceed. A fail result halts the pipeline, generates an alert, and produces a remediation report identifying the location and type of each detected secret. The pipeline configuration should be immutable or change-controlled (AG-407) so that the scanning gate cannot be removed or bypassed without authorised approval.
• Pre-commit scanning with developer feedback. In addition to the mandatory pipeline gate, implement pre-commit hooks that scan staged changes for secrets before they are committed to version control. This provides early feedback and prevents secrets from entering the repository history (where remediation is more complex). Pre-commit scanning is a SHOULD requirement — it is the first line of defence but is not a substitute for the pipeline gate because developers can bypass local hooks.
• Allow-list management with review cadence. Maintain an allow-list of known false positives — strings that match secret patterns but are not secrets (e.g., example API keys in documentation, test fixtures, placeholder values). Each allow-list entry should include: the specific string or pattern, the reason for the exemption, the approver, and the expiration date. The allow-list should be reviewed and re-approved at least quarterly to prevent stale entries from masking genuine secrets.

Anti-patterns to avoid:

• Scanning only the final filesystem of container images. As described above, secrets in intermediate layers are invisible to final-filesystem scanning but fully recoverable by anyone who pulls the image. This is one of the most common bypass vectors for naive scanning implementations.
• Relying solely on pattern matching. Pattern matching detects known secret formats but misses custom or novel credential types. Entropy analysis is essential as a complementary technique to detect secrets that do not conform to known patterns. Conversely, relying solely on entropy analysis produces excessive false positives. The combination is required.
• Making the scanning gate bypassable. If the scanning gate can be skipped by setting an environment variable, passing a command-line flag, or obtaining manual approval, it will be skipped during emergencies — precisely when the risk is highest. The gate must be architecturally non-bypassable. The only path to deployment must pass through the scanner.
• Scanning without remediation integration. Detecting a secret is necessary but insufficient. If the detection does not trigger a credential rotation workflow, the exposed secret remains valid and exploitable even though deployment was blocked. The scanning system must integrate with the credential lifecycle management process (AG-012) to ensure that detected secrets are rotated, not merely flagged.
• Treating development environments as out of scope. Secrets embedded in development environment artefacts are still secrets. Development databases often contain production-quality data. Development API keys often have production-equivalent permissions. Scanning should cover all environments, with the mandatory blocking gate at the promotion boundary to non-development environments.

Industry Considerations

Financial Services. Financial institutions face particularly severe consequences from credential exposure due to the direct financial value of the systems protected by those credentials. Payment processing credentials, trading system API keys, and banking partner authentication tokens are high-value targets. Regulatory expectations under DORA, PCI DSS, and FCA SYSC require demonstrable credential protection controls. Scanning must cover all artefact types specific to financial AI deployments, including model configurations for pricing engines, risk calculators, and fraud detection systems.

Crypto/Web3. Private keys in Web3 deployments are uniquely consequential because blockchain transactions are irreversible. A leaked private key that controls a smart contract or a custodial wallet can result in immediate, total, and unrecoverable loss of assets. Scanning must include detection of wallet private keys, mnemonic seed phrases, and smart contract deployment keys. The scanning sensitivity for Web3 deployments should be set to the highest level with zero tolerance for unresolved detections.

Healthcare. Healthcare AI deployments may embed credentials for electronic health record systems, DICOM image stores, and clinical data warehouses. Exposure of these credentials can lead to HIPAA violations with per-record penalties. Scanning must cover healthcare-specific credential formats and integration endpoint configurations.

Edge and Robotic Deployments. Artefacts distributed to edge devices are particularly vulnerable to credential extraction because the device may be in a physically insecure location. Any credential embedded in an edge deployment artefact should be assumed extractable. Scanning is the last opportunity to prevent credential distribution to physically insecure environments.

Maturity Model

Basic Implementation — The organisation has integrated a secrets scanning tool into the deployment pipeline as a blocking gate. The scanner uses pattern matching for known secret formats (API keys, private keys, connection strings) and runs against the deployment artefact before promotion to staging or production. Detected secrets block deployment and generate alerts. An allow-list exists for known false positives. This level meets the minimum mandatory requirements but may miss secrets in non-standard formats, intermediate container layers, or version control history.

Intermediate Implementation — All basic capabilities plus: the scanning engine combines pattern matching, entropy analysis, and known-format detection. Container images are scanned at the layer level, detecting secrets in intermediate build stages. Version control history is scanned for secrets committed in prior commits. Pre-commit hooks provide developer feedback before secrets enter the repository. Scanning results are integrated with the build pipeline attestation record (AG-407). Detected secrets automatically trigger credential rotation workflows via AG-012. The allow-list is reviewed and re-approved quarterly with documented review records.

Advanced Implementation — All intermediate capabilities plus: the organisation monitors public repositories, container registries, and paste sites for leaked credentials matching organisational patterns. Automated remediation revokes detected secrets immediately upon detection without waiting for manual intervention. Scanning coverage is verified through red-team exercises that deliberately embed test secrets in various artefact types and locations to confirm detection. The scanning rule set is continuously updated based on threat intelligence and new credential format discoveries. The organisation can demonstrate to regulators that no deployment artefact has reached a non-development environment with an embedded secret in the audit period, or that every instance was detected, blocked, and remediated within the SLA.

7. Evidence Requirements

Required artefacts:

• Scanning gate configuration. Documentation of the scanning gate's position in the deployment pipeline, its configuration (enabled detection techniques, rule set version, allow-list), and evidence that the gate is architecturally non-bypassable. Not a description of the intended configuration — the actual deployed pipeline definition.
• Scan execution logs. Immutable audit records for every scan execution over the retention period, showing the artefact identifier, scan timestamp, scanner version and rule set version, scan result (pass or fail), and for failures, the detected secret locations and types. Logs must demonstrate that every deployed artefact was scanned — no gaps for artefacts that bypassed the gate.
• Detection and remediation records. For every detected secret: the artefact in which it was found, the secret location and type, the alert generated, the credential rotation action taken (via AG-012), the time between detection and rotation completion, and confirmation that the artefact was blocked from deployment.
• Allow-list review records. Quarterly review records for the false-positive allow-list, showing each entry reviewed, the reviewer, the decision (retain or remove), and the rationale.
• Scanning coverage verification. Results from periodic testing that verifies the scanner detects secrets across all in-scope artefact types (container layers, IaC templates, runtime bundles, version control history). This may be a canary test programme where known test secrets are deliberately embedded and confirmed detected.

Retention requirements:

• Scan execution logs and detection records: minimum 7 years for regulated financial services; minimum 5 years for other regulated sectors; minimum 3 years otherwise.
• Allow-list review records: minimum 3 years across all sectors.

Access requirements:

• Producible to regulators or auditors within 48 hours of request. Scan execution logs must be queryable by artefact identifier, time range, and scan result. Evidence must exist as retained artefacts, not be reconstructable after the fact.

8. Test Specification

Testing AG-406 compliance requires verifying that secrets are detected across all artefact types, that detections block deployment, that remediation workflows are triggered, and that the scanning gate cannot be bypassed.

Test 8.1: Known Secret Format Detection

• Stimulus: Create deployment artefacts containing secrets in known formats: an AWS access key and secret key pair, a GCP service account JSON key, a GitHub personal access token, a PEM-encoded RSA private key, a database connection string with embedded password, and a JWT signing secret. Embed each secret in a different artefact type (container image final layer, YAML configuration file, Terraform template, runtime bundle startup script, environment variable manifest).
• Expected behaviour: The scanning gate detects all embedded secrets, blocks deployment of all artefacts, and produces a structured rejection identifying each secret's location and type.
• Pass criteria: All six secret types are detected across all artefact types. Deployment is blocked for every artefact containing a secret. The rejection report correctly identifies the file path, line number or byte offset, and secret type for each detection.
• Fail criteria: Any known-format secret passes through the scanning gate undetected, or any artefact containing a detected secret is not blocked from deployment.

Test 8.2: Container Image Layer Scanning

• Stimulus: Build a multi-stage container image where a database password is embedded in a configuration file during an intermediate build stage and deleted in the final stage. The secret is absent from the final filesystem but present in the intermediate layer. Submit the image to the scanning gate.
• Expected behaviour: The scanner decomposes the image into layers, scans each layer independently, and detects the secret in the intermediate layer. Deployment is blocked.
• Pass criteria: The secret in the intermediate layer is detected and reported with the layer identifier and file path. Deployment is blocked.
• Fail criteria: The scanner examines only the final filesystem and fails to detect the secret in the intermediate layer, or the artefact is not blocked from deployment.

Test 8.3: Version Control History Scanning

• Stimulus: Commit a secret (an API key) to a version-controlled repository. In a subsequent commit, delete the file containing the secret. Build a deployment artefact from the current state of the repository (which does not contain the secret in the working tree). Submit the artefact and its source repository to the scanning gate.
• Expected behaviour: The scanner examines the version control history and detects the secret in the prior commit. The detection is reported with the commit hash, file path, and line number. A credential rotation workflow is triggered for the exposed secret.
• Pass criteria: The secret in the version control history is detected and reported. The credential rotation workflow (AG-012) is triggered.
• Fail criteria: The scanner examines only the current working tree and fails to detect the secret in the repository history.

Test 8.4: Deployment Blocking on Detection

• Stimulus: Submit an artefact containing a detected secret to the deployment pipeline. Attempt to override the block via: (a) setting an environment variable commonly used to skip checks, (b) passing a command-line flag to the pipeline, (c) requesting manual override approval, and (d) submitting the artefact directly to the target environment's artefact store, bypassing the pipeline.
• Expected behaviour: All four bypass attempts fail. The artefact does not reach any non-development environment through any path.
• Pass criteria: No bypass mechanism succeeds. The artefact is blocked regardless of the method attempted.
• Fail criteria: Any bypass mechanism allows the artefact to reach a non-development environment.

Test 8.5: Credential Rotation Trigger on Detection

• Stimulus: Embed a known, active credential (a test credential provisioned specifically for this test) in a deployment artefact. Submit the artefact to the scanning gate. Monitor the credential lifecycle management system (AG-012) for a rotation action on the detected credential.
• Expected behaviour: The scanning gate detects the secret, blocks deployment, generates an alert, and triggers a credential rotation workflow via AG-012. The rotation workflow revokes the old credential and issues a replacement.
• Pass criteria: The credential rotation workflow is triggered automatically upon detection. The old credential is revoked within the organisation's defined SLA for emergency rotation. A new credential is issued.
• Fail criteria: Detection occurs but no credential rotation workflow is triggered, or the old credential remains valid after the rotation SLA has elapsed.

Test 8.6: Audit Record Completeness and Immutability

• Stimulus: Execute 10 scan operations: 7 passing and 3 failing. Retrieve the scan execution logs. Attempt to modify or delete a log entry.
• Expected behaviour: All 10 scan executions produce complete audit records with artefact identifier, timestamp, scanner version, rule set version, and scan result. Failing scans additionally include the detected secret locations and types. Modification or deletion of log entries is rejected by the logging system.
• Pass criteria: All 10 log entries are present, complete, and accurate. Modification and deletion attempts fail. The log demonstrates immutability.
• Fail criteria: Any scan execution is missing from the log, any log entry is incomplete, or any modification or deletion of a log entry succeeds.

Test 8.7: Alert Timeliness on Secret Detection

• Stimulus: Submit an artefact containing an embedded secret to the scanning gate. Measure the time between the scan completion (detection event) and the arrival of the alert at the security operations function.
• Expected behaviour: The alert arrives within 15 minutes of detection, containing the artefact identifier, the secret type and location, and the recommended remediation action.
• Pass criteria: Alert is received within 15 minutes with complete diagnostic information.
• Fail criteria: Alert is not received within 15 minutes, or the alert lacks sufficient information to identify the artefact, the secret, or the recommended remediation.

Conformance Scoring

• Score 0: No secrets scanning — deployment artefacts are not inspected for embedded secrets before deployment.
• Score 1: Secrets scanning exists but is advisory only — detections generate warnings but do not block deployment, or the scanning gate is bypassable through documented override mechanisms.
• Score 2: Secrets scanning is implemented as a mandatory, non-bypassable blocking gate with pattern matching and entropy analysis, container layer scanning, audit logging, and integration with credential rotation (AG-012).
• Score 3: Verified by independent adversarial testing — red-team exercises have deliberately embedded secrets across all artefact types and confirmed detection; version control history scanning is operational; public monitoring for leaked credentials is active; and the organisation can demonstrate zero undetected deployments containing secrets in the audit period.

9. Regulatory Mapping

Regulation	Provision	Relationship Type
EU AI Act	Article 15 (Accuracy, Robustness and Cybersecurity)	Supports compliance
EU AI Act	Article 9 (Risk Management System)	Supports compliance
SOX	Section 404 (Internal Controls Over Financial Reporting)	Supports compliance
FCA SYSC	6.1.1R (Systems and Controls)	Supports compliance
NIST AI RMF	MANAGE 2.4, GOVERN 1.7	Supports compliance
ISO 42001	Clause 6.1 (Actions to Address Risks), Clause 8.4 (AI System Lifecycle Processes)	Supports compliance
DORA	Article 9 (ICT Risk Management Framework)	Direct requirement

EU AI Act — Article 15 (Accuracy, Robustness and Cybersecurity)

Article 15(4) requires cybersecurity measures appropriate to the circumstances and risks of high-risk AI systems. Embedded secrets in deployment artefacts represent a cybersecurity vulnerability specific to AI system deployment pipelines. The exposure of authentication credentials could allow an adversary to compromise the AI system, modify its behaviour, access its training data, or pivot to connected systems. AG-406 implements a cybersecurity measure that addresses this vulnerability class, supporting compliance with the Article 15 requirement for appropriate cybersecurity protections.

EU AI Act — Article 9 (Risk Management System)

Article 9 requires identification and mitigation of reasonably foreseeable risks. Accidental credential embedding in deployment artefacts is a well-documented, frequently occurring risk that is clearly foreseeable. The risk management system must include controls to detect and mitigate this risk. AG-406 provides the detective control. The frequency and severity data from industry research makes it difficult for an organisation to argue that this risk was not foreseeable.

SOX — Section 404 (Internal Controls Over Financial Reporting)

For AI agents involved in financial operations, the credentials that the agent uses to access financial systems are internal controls in their own right. If those credentials are exposed through embedding in deployment artefacts, the control environment is compromised. A SOX auditor evaluating AI agent controls will examine how credentials are managed, stored, and protected. Evidence that credentials were embedded in deployment artefacts — even temporarily — represents a control deficiency. AG-406 provides the detective control that prevents this deficiency from reaching production. The audit log provides the evidence that the control was operational during the audit period.

FCA SYSC — 6.1.1R (Systems and Controls)

SYSC 6.1.1R requires firms to maintain adequate systems and controls. Credential management is a fundamental systems and controls requirement. The FCA expects firms to demonstrate that credentials are not exposed through deployment processes and that detection mechanisms exist to identify accidental exposure. AG-406 provides the detection mechanism. The FCA's supervisory approach includes reviewing firms' deployment pipeline security as part of operational resilience assessments, and the absence of secrets scanning would be a finding.

NIST AI RMF — MANAGE 2.4, GOVERN 1.7

MANAGE 2.4 addresses mechanisms for tracking identified AI risks. GOVERN 1.7 addresses the processes and procedures for managing AI system security. Secrets scanning is a security control that manages the risk of credential exposure in AI deployment artefacts. The audit trail from AG-406 provides the tracking mechanism for this risk category, demonstrating that the risk is actively managed through continuous scanning.

ISO 42001 — Clause 6.1, Clause 8.4

Clause 6.1 requires actions to address risks within the AI management system. Clause 8.4 addresses AI system lifecycle processes, including deployment. Secrets scanning addresses the deployment-phase risk of credential exposure and provides a control that operates within the AI system lifecycle process. The scanning gate integrates with the deployment workflow, making security a structural part of the lifecycle rather than an afterthought.

DORA — Article 9 (ICT Risk Management Framework)

Article 9 requires financial entities to have an ICT risk management framework addressing ICT-related risks comprehensively. Credential exposure through deployment artefacts is an ICT risk that directly threatens the confidentiality and integrity of financial systems. DORA's emphasis on operational resilience requires that credential exposure be detected before it can cause operational disruption. AG-406 implements the detection mechanism, and its integration with AG-012 (credential rotation) ensures that detected exposures are remediated before they can be exploited. DORA Article 9(4)(b) specifically requires the protection of ICT assets, which includes the authentication credentials that govern access to those assets.

10. Failure Severity

Field	Value
Severity Rating	Critical
Blast Radius	Dependent on the exposed credential's access scope — ranges from a single system to organisation-wide compromise where the exposed credential provides transitive access (e.g., a vault token or root service account)

Consequence chain: A failure of secrets scanning governance allows deployment artefacts containing embedded credentials to reach non-development environments, where they become accessible to anyone with access to the artefact — including operators, partners, edge device holders, or attackers who compromise the deployment infrastructure. The immediate technical impact is credential exposure: the embedded secret can be extracted from the artefact and used to authenticate to whatever system the credential protects. The operational impact depends on the credential's access scope: a single database credential exposes one database; a service account key may expose multiple systems; a vault or secret management token exposes the entire credential infrastructure, enabling cascading compromise of every system whose credentials are managed by the vault. For AI agent deployments specifically, exposed credentials may grant the ability to: modify model artefacts (undermining AG-405), alter governance policy bundles (undermining AG-001 through AG-009), access training data containing PII (triggering AG-015 obligations), impersonate the agent on authenticated channels, or access financial systems through the agent's payment credentials. The business consequence includes: regulatory enforcement action for inadequate credential management (DORA, FCA SYSC, PCI DSS); data protection violations if the exposed credential provides access to personal data (GDPR, CCPA); financial loss if the credential provides access to payment or trading systems; the operational cost of emergency credential rotation across all affected systems (which routinely causes service disruptions); and the forensic and legal cost of investigating the scope of compromise. The cost of remediation after deployment consistently exceeds the cost of detection before deployment by two orders of magnitude. The reputational impact is particularly acute because credential embedding is widely regarded as a basic, preventable failure — an organisation that deploys secrets in artefacts will face scrutiny on whether its broader security posture is adequate.