Best Practices for Secretless Engineering Automation

A CI/CD pipeline deploying to production. A nightly database backup job. An AI agent performing maintenance tasks. New opportunities for engineering automation emerge every day.

However, many of these workflows depend on stored secrets like hardcoded credentials, API keys, and long-lived tokens for privileged access.

Secrets management and credential handling processes intended for human users — including legacy privileged access management (PAM) and vaulting tools — are unable to keep up with the speed of automation and the growing scale of modern environments.

This creates several challenges.

The “Secret” Barriers to Secure Engineering Automation

“As complexity and scale inevitably reach a certain moment, the mere existence of a secret anywhere in a computing environment is considered a liability.”

Jack L. Poller, Paradigm Technica, Infrastructure Identity: A New Paradigm for Trustworthy Computing in a Zero Trust World

Shared and stored secrets create two core blockers to the adoption and implementation of engineering automation:

• The increased attack surface of persistent autonomous secrets is too great.
• The extra manual effort required to secure secrets in automation workflows outweighs the potential efficiency gains.

These barriers to secure — and productive — automation manifest in several ways.

Secrets sprawl

Even when “managed” in vaults, secrets must be distributed to the services that need them. Each transfer requires human coordination or complex scripting, creating friction in systems designed to run continuously.

In AI and automation workflows, this slows deployment and can increase risk if old, forgotten secrets continue to grant access without continuous policy enforcement.

Limited identity visibility

Stored secrets are often shared. Once a credential is retrieved from a vault or embedded in a script, it may be used by multiple people or services — making it impossible to link actions to a single identity.

In From Cost Center to Business Catalyst, analysts from HyperFRAME Research note that:

“Without unified identity visibility, it becomes nearly impossible to tell whether a human is performing the work or whether an AI agent or bot is acting with borrowed credentials.”

Persistent breach risks

Verizon’s 2025 Data Breach Investigations Report highlights that credential abuse remains the top initial access vector for data breaches.

Once a secret is retrieved, it becomes susceptible to theft, reuse, or leakage. Even if encrypted in storage, a secret becomes vulnerable the moment it enters a configuration file or process log.

Operational complexity

Managing secrets requires manual maintenance that, if unaddressed, can undermine the gains of automation. At scale, these manual processes also increase risk.

As OWASP explains in their Secrets Management Cheat Sheet:

“Manual maintenance does not only increase the risk of leakage; it introduces the risk of human errors while maintaining the secret.”

This operational burden grows as environments expand, increasing the risk of human error leaving secrets unrevoked, unrotated, or misconfigured.

Compliance gaps

Compliance frameworks like SOC 2 and ISO 27001 require organizations to prove that secrets are properly managed, in addition to proof of who accessed what and why access was allowed.

Static credentials complicate this by separating authentication from authorization. Vaults track checkouts; not effective permissions or real-time context.

Best Practices for Securing Automation Without Secrets

To overcome the security and operational risks of traditional secrets management, organizations need to rethink how trust is established in their digital estate.

Instead of relying on static credentials that must be created, distributed, and protected, the strategic goal is to move toward secretless automation — where authentication is automatic, short-lived, and contextualized to the workload or identity itself.

Here are five practices to implement this strategy:

1. Prioritize end-to-end credential lifecycle automation

• Focus on fully automating how machine identities and credentials are managed.
• Ensure credentials are short-lived and created just-in-time for workloads at runtime.
• Set a clear ownership model so security, platform, and application teams understand who governs policies versus who operates the automation.

2. Move to context-aware, policy-driven access

• Replace static secrets with access decisions that evaluate context at every request, including environment, workload, risk level, and business criticality.
• Define central policies that can deny or adjust access dynamically when context changes (e.g., environment, workload posture, anomalous behavior) without requiring manual key revocation.
• Align authorization policies with business risk, so the most critical systems benefit first from fine-grained, context-aware control.

3. Embed Zero Trust into machine-to-machine communication

• Treat all network paths as untrusted and rely on strong, mutual authentication (such as mTLS) between services, applications, and infrastructure components.
• Ensure encryption and identity verification are enforced by default for internal service-to-service and application-to-database traffic, not just external connections.
• Standardize enterprise-approved patterns for secure service communication to reduce exceptions.

4. Make identity the foundation of observability and accountability

• Replace shared secrets and generic service accounts with unique identities for each workload, microservice, automation job, and bot.
• Require that security logs and audit trails capture these identities consistently so investigations can quickly answer “who or what accessed what, and when?”.
• Use identity-centric telemetry to improve signal quality and reduce investigation time.

5. Treat security for automation as continuous

• Govern access and identity policies as code — version-controlled and reviewed — rather than relying on ad hoc changes in GUIs or one-off scripts.
• Avoid “hot fixes” to permissions on live systems wherever possible; instead, update policy definitions, roll them out through your standard deployment process, and let automation apply new identities and permissions.
• Establish KPIs and review cadences (e.g., standing privilege reduction, percentage of workloads using short-lived identities, audit coverage) to continuously measure and improve your automation security posture.

Cryptographic Identity: The Foundation of Secretless Automation

Secretless automation at scale requires a mechanism that can issue, verify, and expire access automatically. Cryptographic identity provides the technical foundation that makes this possible.

While a secret is something you have (like a password), a cryptographic identity is proof of who you are. It replaces static strings of text with verifiable digital certificates (such as X.509 or SSH certificates) that are issued at runtime and expire automatically.

Teleport issues cryptographic identity to every participant involved in infrastructure access, including users, machines, bots, workloads, resources, and devices. Because everything has an identity that is tied to a biometric or comparable attribute (such as a TPM, or a secure enclave for hardware), Teleport establishes trusted computing without secrets.

Secretless Automation in Real-World Pipelines

Before:

A DevOps team manages access to production systems using stored secrets like passwords, API keys, and tokens.

• Secrets are checked out from a vault and embedded in scripts.
• Each credential must be rotated and updated manually.
• Deployments pause while teams coordinate key distribution and audits.

This slows down automation and increases risk. Logs may show which secret was used, but not which process or service used it, leaving security teams with gaps in visibility.

After:

With Teleport and cryptographic identity, authentication happens automatically using short-lived certificates instead of static keys.

• Each service or job receives a unique, temporary credential issued at runtime.
• Credentials expire automatically when the process ends.
• Authorization is enforced in real time based on identity and policy.

Conclusion

Stored secrets were a necessary bridge between manual and automated systems. But as automation use cases grow in scale, those secrets — and the processes required to manage them — are barriers to secure and efficient automation.

Cryptographic identity offers a practical way forward to eliminate legacy PAM secrets management and establish trusted computing, even in autonomous environments. With no stored secrets to manage or lose sleep over, organizations can turn their automation vision into reality.

Further Reading

• What is Cryptographic Identity?
• Credentials vs. Cryptographic Identity
• What is Privileged Access Management (PAM)?
• What is the Model Context Protocol (MCP)?
• Your Infrastructure Has a Non-Human Trust Problem
• Vault-Free Privileged Access Management (PAM)
• Secure Model Context Protocol (MCP)
• Secure Agentic AI