Introduction: The Expanding Attack Surface of Identity
In today’s digital landscape, secrets and Non-Human Identities (NHIs) form the connective tissue of nearly every enterprise system. Whether it’ s a database password, an API key embedded in a script, or a Kubernetes service account token, these credentials enable the communication, automation, and scalability that modern infrastructure demands.
Yet the very ubiquity of secrets and NHIs makes them an urgent risk. Secrets sprawl across environments without clear ownership or lifecycle. NHIs — such as CI/CD roles, cloud service accounts, and machine-learning pipeline agents — operate autonomously, often with little oversight. And attackers know this. Over the past several years, credential-based breaches have become routine, from the theft of hardcoded AWS keys to the misuse of over-permissioned machine accounts.
This white paper offers a comprehensive, security-focused guide to controlling secrets and NHIs. It outlines practical strategies that security teams can deploy today — not just to reduce risk, but to align with compliance frameworks and enable secure automation at scale.
The State of Secrets: From Sprawl to Strategy
Why Secrets Are Still the Weakest Link
Secrets are often treated as implementation details — passed from DevOps to development teams, from infrastructure teams to CI systems, and from automation scripts to production servers. The result is predictable: secrets proliferate unchecked. In 2024 alone, over 23 million secrets were exposed on GitHub, and research shows that 70% of those secrets were still valid over a year after they were leaked.
High-profile breaches have repeatedly demonstrated how quickly a leaked credential becomes an entry point. Uber’s 2016 breach, for instance, originated from AWS keys embedded in a Git repository. Once exposed, they allowed attackers to access cloud storage and exfiltrate user data undetected.
Challenges in Secrets Management
Security teams often discover that secrets are:
- Hardcoded into source code or configuration files
- Stored in plaintext in environment variables or logs
- Rotated irregularly — or not at all
- Shared across multiple systems or teams
- Lacking centralized visibility, access control, or auditability
In cloud environments, these problems are exacerbated by speed and scale. Secrets are issued and used by dozens or hundreds of ephemeral services, containers, and automation tools. Without centralized secrets management, controlling this sprawl becomes virtually impossible.
A Security-Centered Solution
Modern secrets management begins with centralization. A central secrets repository such as Akeyless provides a single source of truth for all credentials.
These platforms allow you to:
- Enforce encryption at rest using FIPS-validated key management
- Apply role-based access control and fine-grained permissions
- Automatically rotate secrets on a schedule or after use
- Maintain audit trails of every access and modification
Security teams must ensure that secrets are:
- Never embedded in code
- Fetched dynamically at runtime
- Rotated regularly and expired proactively
- Fully auditable and monitored
This transforms secrets from silent liabilities into actively governed assets.
Non-Human Identities: Securing the Digital Workforce
Defining NHIs
While human users log in with SSO and MFA, the majority of activity in modern systems comes from non-human entities: service accounts, bots, microservices, and automation pipelines. These identities — often referred to as NHIs or machine identities — far outnumber human users and hold extensive privileges across environments.
A Kubernetes cluster might run hundreds of pods, each with its own service account. A CI/CD pipeline might spawn temporary IAM roles to provision infrastructure. A machine learning pipeline might use a long-lived API key to query sensitive data.
Why NHIs Are a Blind Spot
Unlike human identities, NHIs often:
- Lack individual ownership or lifecycle management
- Operate without MFA or contextual restrictions
- Possess broad, persistent access rights
- Are invisible in traditional IAM and access reviews
These characteristics make NHIs attractive targets. A single compromised service account can provide the attacker persistent access — and unless access logs are integrated with behavior-based anomaly detection, it may go unnoticed for days or weeks.
The 2019 Capital One breach is illustrative. An attacker exploited a server-side request forgery vulnerability to access an EC2 instance’s IAM role. That role had overly broad permissions and granted access to customer data in S3. Because the activity was consistent with what the role was permitted to do, traditional IAM monitoring didn’t flag it.
Establishing Control
Security teams must treat NHIs with the same rigor as user identities. That begins with discovery and inventory. Every service account, cloud role, and automation credential should be accounted for, tagged with an owner, and tied to a specific purpose.
From there, organizations should:
- Enforce least privilege on every machine identity
- Segment duties to avoid cross-environment compromise
- Rotate credentials automatically
- Integrate NHI access with SIEM/SOAR workflows
- Review entitlements regularly
This not only reduces attack surface but also aligns with auditor expectations under SOC 2, ISO 27001, and NIST SP 800-53.
Workload Identity: Solving for Ephemerality
The Problem with Static Credentials in Dynamic Environments
Cloud-native architectures rely heavily on short-lived compute — containers, functions, and pods that are spun up and torn down in seconds or minutes. Traditional credential management assumes long-lived systems and human provisioning cycles, making it ill-suited to these environments.
Security risks include:
- Shared secrets baked into container images
- IAM keys stored in environment variables
- Lack of traceability across workload lifecycles
These practices not only expose secrets but also inhibit scalability and resilience.
What is Workload Identity?
Workload identity is the practice of assigning verifiable, short-lived identities to ephemeral compute workloads.
This can be achieved through:
- Kubernetes service account tokens
- Cloud-native integrations (e.g., AWS IRSA, GCP Workload Identity)
- OIDC-based federated tokens
- mTLS certificates issued by SPIFFE/SPIRE
The result: each container, function, or pod receives an identity dynamically, scoped to its context (namespace, cluster, workload name), and with a time- bound token or certificate.
Security Benefits
- No secrets stored in images or configuration
- Access governed by policy, not manual provisioning
- Full traceability and revocation capabilities
- Strong alignment with Zero Trust architecture
Security professionals should ensure that these systems are not optional — they should be enforced via policy and validated continuously as part of deployment pipelines.
Moving Toward a Secretless Architecture
What Does “Secretless” Mean?
Secretless architecture replaces stored static credentials with ephemeral, identity-based access — often achieved via federation, IAM roles, or mTLS certificates. Applications authenticate at runtime without “knowing” a secret.
How It Works
Workload identity is the practice of assigning verifiable, short-lived identities to ephemeral compute workloads.
This can be achieved through:
- A cloud workload retrieves a short-lived token from an identity provider
- A proxy or broker retrieves credentials on behalf of the app, abstracting away secrets
- A container accesses AWS resources using its IAM role via the instance metadata service
Benefits:
- No secrets to leak, rotate, or revoke manually
- Simplifies secure app deployment (no secret injection steps)
- Enforces Zero Trust and ephemeral access by design
Getting There
- Audit and identify static secrets currently in use
- Migrate low-risk systems first (e.g., dev/test pipelines)
- Implement federation with your IdP across clouds and platforms
- Educate developers and enforce code hygiene (no secrets in code)
- Monitor identity issuance systems (e.g., STS, OIDC, Vault) as critical infrastructure
Securing AI and Automated System Identities
Why AI Identity Security Matters
AI systems—like ML training pipelines, inference models, and RPA bots—use identities to access data, APIs, and infrastructure. These identities are often over-permissioned, poorly monitored, and vulnerable to misuse.
Unique Risks
- Autonomy at scale: AI systems can make thousands of requests without oversight
- Emergent behavior: AI agents might perform unintended or harmful actions
- Credential leakage: Hardcoded model-serving tokens or API keys are common
- Data privacy concerns: AI access to personal data must comply with GDPR and HIPAA
Best Practices
- Assign unique, non-shared identities to each AI component
- Scope access narrowly and tie it to specific datasets/tasks
- Use ephemeral tokens for training and inference pipelines
- Monitor access and behavior for outliers or misuse
- Secure model artifacts and tie access to governance policies
Compliance Alignment
Proper secrets and identity management directly supports key compliance requirements:
- SOC 2: Secure authentication and authorization (CC6), audit logging (CC7), and change management (CC8)
- ISO 27001: Controls A.9 (Access Control), A.10 (Cryptography), A.12 (Operations Security)
- NIST 800-53: IA-5 (Authenticator Management), AC-6 (Least Privilege), SC-12 (Key Management)
- GDPR: Article 32 (Security of Processing), Article 5 (Accountability, Data Minimization)
Security teams can leverage secrets and NHI practices to proactively answer audit questions, demonstrate control maturity, and reduce audit fatigue across the organization.
Conclusion: Identity is the New Perimeter
As traditional perimeters dissolve, identity — particularly Non-Human Identity — has emerged as the new control plane for security. Secrets, service accounts, and machine credentials represent the front lines of both attack and defense.
Security teams must respond by:
- Centralizing and automating secrets management
- Establishing visibility and governance over NHIs
- Securing ephemeral workloads through dynamic identity
- Eliminating embedded credentials wherever possible
- Applying these controls uniformly to AI systems and cloud-native platforms
This is not just a tactical shift — it is a strategic upgrade in how organizations secure the digital enterprise. By treating identity as the foundation of infrastructure security, security leaders can reduce breach risk, accelerate compliance, and enable secure innovation at scale.
Why Akeyless
Akeyless is purpose-built to help security teams regain control over secrets and Non- Human Identities at scale. As a SaaS-based, zero-knowledge platform powered by Distributed Fragments Cryptography TM (DFC), Akeyless eliminates the operational burden of self-hosted vaults while maintaining the highest levels of control and privacy.
With Akeyless, your team can:
- Centrally manage secrets, credentials, and encryption keys across multi-cloud and hybrid environments
- Automate rotation, expiration, and just-in-time provisioning to reduce risk and overhead
- Enable secretless authentication for AI agents and machine identities
- Extend secrets governance to ephemeral workloads, CI/CD pipelines, and serverless architectures
- Achieve continuous compliance with built-in audit logging, access control, and policy enforcement
Unlike traditional vaults, Akeyless provides the ease of SaaS scalability while never having access to your secrets, your keys, or your infrastructure. You maintain complete ownership, with zero compromise.
