Secrets in the Age of AI Agents: A Control Architecture for Software Delivery

Secret management has become a systems problem

For years, secret management in software development was treated largely as a hygiene problem. Developers were expected not to commit passwords, API keys or database credentials to source control; environment files were excluded through .gitignore; production credentials were stored somewhere more protected; and experienced engineers learned which commands, files and debugging practices were considered unsafe.

That model emerged when the development environment was comparatively simple. A human opened an editor, a human ran the shell and a relatively small number of tools interacted with the local machine. The operating assumption was that the developer was both the user of the credentials and the primary observer of the environment in which those credentials existed.

AI-assisted engineering changes that assumption.

A coding agent may legitimately inspect source files, search the repository, execute commands, read build output, diagnose deployment failures, modify configuration, generate scripts and interact with infrastructure tooling. Depending on the platform and operating model, parts of those interactions may also appear in execution traces, tool outputs, logs or conversational history. The agent does not have to behave maliciously for the security model to weaken. It only has to perform the work it was authorized to perform in an environment where credentials were never designed for multiple automated readers.

The resulting question is larger than whether an agent should be allowed to open .env.local. The real question is whether an enterprise can prove where a secret originated, who or what was permitted to retrieve it, where it could be materialized, which process received it, whether unrelated subprocesses inherited it, which version reached production and whether a release or diagnostic workflow could accidentally persist it somewhere else.

Once those questions become relevant, secret management stops being a file-management practice. It becomes part of the software delivery architecture.

The local environment file is output, not custody

The familiar environment file is not inherently insecure. The more consequential issue is the role organizations allow it to play.

A local environment file can be a practical compatibility layer for frameworks that expect configuration in environment variables. The architectural mistake is allowing that file to become the place where credentials are originally created, manually curated or indefinitely stored. Once developers copy API keys, database passwords and other credentials into hand-maintained files, the organization has created a second secret store without most of the properties expected from one: no reliable version history, weak access governance, limited auditability, uncertain rotation, inconsistent deletion and an expanding set of tools capable of reading it.

A stronger model changes the direction of authority. The managed secret store remains authoritative; local materialization, where permitted, is generated from that authority for a specific purpose. The local file becomes disposable rather than canonical.

That distinction matters particularly in an agent-enabled engineering environment. A generated development file can be recreated, restricted to development credentials, written with controlled permissions and mechanically prevented from retrieving higher-environment values. The control no longer depends on an instruction telling an agent or developer not to fetch production. The retrieval path itself does not permit it.

Production should be treated differently again. In a mature model there is normally little reason for production credentials to materialize on a developer workstation at all. They can move from their controlled source through an authenticated delivery process to the runtime that consumes them without becoming a routine local artifact.

The objective is therefore not to eliminate environment variables. It is to eliminate unmanaged credential custody disguised as environment configuration.

Start with the lifecycle of the secret

A useful architecture begins by separating stages that are often collapsed into the word “secret.”

A secret first has an origin. A database may issue a credential, an external platform may create an API token, an application may require a cryptographically generated signing value or an identity provider may issue client credentials. The origin matters because the safest path generally minimizes intermediate copying between creation and controlled storage.

The secret then has custody. A managed secret service, vault or equivalent control becomes the authoritative location from which governed consumers can retrieve the value. Custody should include access policy, versioning, rotation capability and auditability.

The system separately needs declaration. Applications must describe what secrets they require, in which environments, for which runtime and potentially how their presence should be verified. This information is structural and does not require revealing the secret itself. A declarative manifest is therefore useful because it allows humans and agents to reason about requirements without reasoning about values.

Next comes transport. Some process has to move an authorized value from custody to the consuming runtime. In modern delivery systems that process is normally CI/CD rather than a developer manually copying the credential. Transport is where identity becomes critical.

Finally there is consumption and verification. The fact that a value exists in a vault does not prove the consuming system can use it. A credential can be expired, malformed, issued for the wrong account, associated with the wrong environment or technically valid while pointing at the wrong resource. Verification should therefore test the system-level property that matters rather than merely confirming that a non-empty string exists.

Separating these stages creates an important governance distinction: the application can declare its secret requirements without owning secret values, an AI agent can manipulate those declarations without reading credentials and CI can transport production values without becoming their permanent storage location.

Identity should replace stored deployment credentials

The strongest secret is often the credential that no longer needs to exist.

Traditional CI/CD frequently relies on a long-lived service-account key or cloud credential stored as another secret inside the CI platform. This creates a recursive problem: the organization introduces a vault to protect application credentials but still needs a powerful standing credential to reach the vault.

Workload identity changes that relationship. Instead of storing a reusable cloud key, the CI workload proves its identity through a trusted federation mechanism and receives short-lived authority appropriate to the job it is running.

The security improvement is not simply shorter credential lifetime. It is the ability to bind authorization to the properties of the workload itself. An enterprise can distinguish development, staging and production pipelines; constrain trust to a specific repository; constrain production access to a specific branch or protected deployment environment; and give each workflow only the permissions required for its role.

This becomes increasingly important when automated agents can initiate or modify parts of the delivery process. A repository-level instruction saying “never deploy to production” is weaker than an architecture in which a development identity has no production permission, a production candidate workflow requires a different trust path and traffic promotion is controlled separately from secret retrieval.

Good identity architecture converts organizational intent into an authorization graph.

Separate identity, custody, release and runtime

Many security weaknesses arise because several logically different control planes are collapsed into one pipeline.

A more resilient design separates at least four.

The identity plane determines who or what is acting. This includes developers, CI workloads, deployment workflows and operational automation.

The secret custody plane determines where credential values live, who may create new versions, who may retrieve them and which environments remain isolated from one another.

The release control plane determines which version of the application is a candidate for deployment and which candidate receives traffic.

The runtime plane is where the application actually consumes its configured bindings and communicates with databases, APIs, queues, storage systems and other services.

This separation produces stronger failure containment. A production promotion operation, for example, may need authority to change traffic allocation but does not necessarily need authority to retrieve database passwords. A rollback operation may need to reactivate a previously validated application version without reading the secret store again. A development workflow may need access to development credentials while remaining structurally unable to reach production custody.

The architecture becomes easier to reason about because authority follows responsibility.

This is also why environment isolation should be treated as a security boundary rather than a naming convention. Development, staging and production may use similar application structures, but the identities and secret domains behind them should not automatically be interchangeable. For higher-risk systems, stronger separation may extend to distinct cloud projects or accounts, independent service identities and separate deployment protections.

The relevant question is not whether every organization needs the maximum possible isolation. It is whether an environment compromise can cross into another environment merely because the architecture assumes everyone will behave correctly.

AI agents need capability boundaries, not instructions alone

Enterprise agent governance often begins with policy prompts: do not read credential files, do not reveal secrets, do not execute production commands, do not modify certain resources.

Those instructions are useful, but they should not be confused with security boundaries.

An engineering agent can solve problems by creating new scripts, renaming files, invoking subprocesses, generating code, calling other tools or reorganizing the workflow around an obstacle. This flexibility is precisely what makes the agent valuable. It also means that blocking one filename or one command string is not equivalent to blocking the underlying capability.

A policy that says “do not read .env.local” controls one path. It does not necessarily control a copied file with another name. A shell rule that rejects a direct secret-retrieval command may not control a script that executes the same retrieval inside a subprocess. A rule written entirely around what an agent types may not inspect what the agent writes for later execution.

The more durable governance boundary is based on the movement of the secret value itself.

An AI agent can safely perform a large amount of structural work without seeing credentials. It can declare required variables in a manifest, update schemas, create CI workflows, validate resource references, prepare deployment candidates, compare versions, inspect value-free release metadata and diagnose failures whose outputs have been designed not to disclose secrets.

Provisioning a sensitive value is different because the value itself crosses the interaction boundary. That action can remain human-controlled or be performed by a trusted non-agent automation path whose authority is independently governed.

This produces a useful operating rule: delegate structure aggressively; constrain secret custody explicitly.

The goal is not to make AI agents powerless. It is to make their authority legible.

Deterministic enforcement has to inspect effects

Once organizations accept that instructions are insufficient, enforcement moves closer to the tools.

A robust agent environment can inspect attempted reads, shell commands, searches and file modifications before execution. It can reject known secret-bearing paths, but stronger enforcement also examines the content being created. If an agent attempts to write a helper script whose purpose is to retrieve protected credentials, the architecture should not consider the operation safe merely because the target filename is innocuous.

This is a general principle for autonomous systems: guardrails should operate on the effective capability being introduced, not only the superficial syntax of the current request.

There are practical limits. Static inspection will never perfectly understand every program an agent could write, and security teams should be cautious about presenting pattern matching as a complete sandbox. That is why enforcement works best in layers. Tool-level deny rules can remove common paths, pre-execution hooks can inspect actions, cloud IAM can limit what the resulting process could obtain, environment separation can restrict blast radius and CI policies can reject unsafe workflow structures before they are merged or executed.

The layers are intentionally redundant because each answers a different question.

Can the agent request the action? Can the local tool execute it? Can the resulting process authenticate? Can that identity access the resource? Can the workflow promote the result? Can the operation be audited afterward?

When those questions are independently controlled, agent safety is no longer dependent on the agent interpreting a paragraph of instructions exactly as its authors intended.

Secret security and software supply-chain security converge in CI

A secret-management architecture can still fail if the process holding the secret executes untrusted tooling.

This is why software supply-chain controls belong inside the same design.

Consider a CI job that has just authenticated to a cloud provider and retrieved an application secret. If the next command dynamically downloads an unpinned package, installer or deployment utility, the organization has allowed new code to enter precisely when the process holds its most sensitive authority.

The safer sequence is deliberate. Dependencies are resolved from lockfiles and installed before privileged cloud authentication where possible. CI actions are pinned to immutable revisions. Deployment CLIs are repository-local or otherwise installed at explicitly reviewed versions. Dynamic package execution is avoided in secret-bearing processes. If a cloud CLI must be installed as part of the workflow, its version is explicit rather than whatever happens to be “latest” on the day the pipeline runs.

There is another, less visible boundary: child-process inheritance.

Operating systems make it convenient for a subprocess to inherit the parent environment. Convenience is not the same as least privilege. If a process simultaneously holds cloud identity variables, deployment-platform tokens and application secrets, blindly forwarding the complete environment to every child gives unrelated tooling credentials it never requested.

A stronger model constructs the environment for each subprocess deliberately. The cloud utility gets the cloud identity it requires. The deployment utility gets its deployment authorization. A password-hashing helper receives the value it must hash through a protected input channel and does not inherit unrelated cloud tokens. Git, test runners and diagnostic utilities receive neither unless necessary.

The principle is simple: process boundaries are security boundaries too.

Releases should preserve exact provenance without preserving secrets

Modern runtime platforms increasingly distinguish the artifact being released from the decision to route traffic to it. That distinction is extremely useful for secure secret handling.

A release candidate can be constructed from an exact code revision, exact dependency state, exact configuration and exact numbered secret versions. The credential values themselves do not belong in release metadata, but the identifiers of the versions used can.

This creates reproducibility without creating another credential store.

For a production candidate, the release system can record that a particular database secret version, API credential version and signing-secret version were used, alongside the source commit, build run, deployment-tool version and runtime version identifier. If the candidate passes validation, traffic can later move toward it progressively. Promotion no longer needs to reread the secret store because it operates on an already constructed runtime version.

That architecture also improves rollback. Returning traffic to a previously stable version is a traffic-control decision rather than an attempt to reconstruct the past using whatever secret values happen to be current now.

There is an important data-governance implication. Release metadata should be allow-listed, not simply whatever a deployment CLI returns. External tools evolve, output schemas change and new fields appear. Persisting arbitrary command output makes the safety of the audit trail dependent on upstream implementation details. A mature release system records only the identifiers and provenance fields it has explicitly decided are safe.

Exactness matters here. “Latest” is convenient for interactive work but ambiguous for auditability. A numbered secret version establishes which value was actually consumed. A version should also be checked for its operational state rather than assuming the numerically newest version is usable.

The objective is not bureaucratic traceability. It is the ability to explain a production state precisely without exposing the credentials that created it.

Verification has to test consumption, not appearance

Secret-management controls often stop too early.

A script verifies that a variable exists. A deployment check confirms that the value is non-empty. A human sees something credential-shaped and assumes provisioning succeeded. None of these tests establish that the system works.

A placeholder may be syntactically valid. A URL may contain a real hostname but the wrong database. A key may have the expected length while belonging to another application. A token may exist in the vault but have been revoked at its source.

Verification should therefore be designed around consuming-system assertions.

For a database credential, that might mean resolving the expected host and performing an authenticated connection using a safe verification path. For an external API, it may mean calling a low-risk authenticated endpoint. For a generated signing secret, verification may focus on required entropy and successful initialization rather than an external service.

The test should prove the property that matters while minimizing disclosure.

Freshness is part of the same problem. Development credentials materialized locally can become stale after rotation. A generated local file can therefore carry non-secret metadata indicating when it was produced, which manifest it corresponds to and which numbered secret versions were used. A freshness check can compare those identifiers with the vault without printing credential values.

This turns “my local environment is probably current” into something the system can evaluate.

A maturity model for agent-ready secret management

Organizations do not need to redesign every development platform at once. The transition is more manageable when sequenced around custody and authority.

At the first stage, inventory existing secret paths. The important output is not simply a list of credentials but a map of where they originate, where they are copied, which environments permit local materialization, which CI jobs retrieve them, and which processes inherit them.

The second stage establishes an authoritative secret store and a declarative inventory. This separates the question “what does the application need?” from “what are the values?” and makes it possible for automated engineering systems to manipulate requirements without accessing credentials.

The third stage removes standing deployment credentials through workload identity or equivalent short-lived federation. Environment-specific identities should follow the principle of least privilege, with production retrieval, candidate creation, promotion and rollback separated where their responsibilities differ.

The fourth stage constrains local materialization. Development secrets may still be generated locally where needed, but higher environments become inaccessible from ordinary workstation flows. Files are created by controlled tooling with safe permissions and become disposable artifacts rather than developer-maintained records.

The fifth stage introduces deterministic agent and CI enforcement: pre-execution controls, write-content inspection, immutable action references, pinned deployment tooling, restricted subprocess environments, protected release paths and structural workflow policy checks.

The final stage makes release provenance explicit. Exact secret-version identifiers, code revisions, dependency hashes and runtime versions become part of a safe audit record, while production promotion and rollback operate without unnecessary secret-store authority.

These stages are cumulative. A sophisticated agent hook cannot compensate for a CI service account with unrestricted production access, just as perfect IAM cannot prevent a developer from manually copying a production credential into a local note. The strength comes from the system of controls.

What leadership should govern

Secret management in an AI-enabled engineering organization crosses several executive domains. Engineering leadership owns developer experience and delivery architecture. Security leadership owns identity, custody and policy. Platform teams own CI/CD and runtime integration. Application teams own declarations and consuming-system verification. Procurement and technology governance may also influence which agent platforms, observability systems and external tools are permitted to process development context.

Without an explicit operating model, each team can optimize its part while leaving gaps between them.

Executives should therefore ask for evidence around a small number of architectural properties rather than an inventory of security tools.

• Can production credentials reach ordinary developer machines?
• Does CI rely on standing cloud keys or federated workload identity?
• Can development authority cross into staging or production?
• Can an AI agent access secret values directly, or only declare the structure that requires them?
• Can the organization detect an agent attempting to create an indirect secret-access path?
• Are dependency installation and dynamic tool resolution separated from privileged execution?
• Does every subprocess receive all parent credentials by default, or only what it requires?
• Can the organization state exactly which secret versions entered a production release without retrieving those values again?
• Can production traffic be promoted or rolled back without granting the operation unrelated secret-store authority?
• Does verification prove that credentials work with the system that consumes them?

These questions are more useful than asking whether a team “uses a vault,” because a vault is only one component of the custody chain.

The management implication: design for autonomous operation

The arrival of AI agents exposes something that was already true about software security: systems that remain safe only when an experienced engineer remembers the unwritten rules are not strongly governed systems.

Human-operated development tolerated many such conventions because humans supplied context continuously. They knew which file was dangerous, which command was only for development, which deployment required a second check and which credential should never leave a particular machine.

Autonomous and semi-autonomous engineering removes some of that implicit context. The response should not be to recreate it through ever-longer instruction files. It should be to convert the important parts into architecture.

A mature secret-management model therefore has a recognizable shape. Applications declare what they require without storing values. Sensitive values move from controlled origins into governed custody. Humans or trusted provisioning automation introduce those values without routing them through an agent conversation. Workloads authenticate through identity rather than permanent keys. Development materialization is constrained by environment. CI transports values through scoped processes. Runtime versions preserve exact provenance without persisting the credentials themselves. Promotion and rollback have only the authority they need. Verification proves consumption. Agent controls inspect capabilities, not merely filenames.

Under that model, greater automation does not require weaker control. It can produce the opposite. Once the boundaries are explicit enough for an autonomous system to operate safely inside them, they also become clearer for humans, auditors and engineering leaders.

That is the larger architectural opportunity created by AI-assisted software delivery. The objective is not simply to stop an agent from reading a secret. It is to build a delivery system in which neither an agent nor a human has to rely on discretion to keep the secret where it belongs.