Identity Management

Non-Human Identity and Access Management

Skill 7 of 9 | Pillar III: Trust & Security

The security foundation for the age of autonomous agents—treating AI systems as first-class identity citizens with their own credentials, permissions, and audit trails.

When Agents Become Actors

Here's a security truth that many organizations learn the hard way: the era of embedding static API keys in code is over. When agents become autonomous actors—performing actions on behalf of users and organizations, accessing sensitive data, making decisions that affect the real world—they must be treated as distinct, verifiable identities with the same rigor we apply to human users.

Skill 7 represents a critical evolution in security thinking for agentic AI systems. Traditional approaches treated agents as extensions of user sessions or as faceless services with shared credentials. But autonomous agents require something fundamentally different: their own service principals, dynamic credentials, complete audit trails, and least-privilege access controls.

Consider the risk: an agent with a static API key embedded in code has that key forever, with whatever permissions were granted at creation time. If the key is compromised—through a code repository leak, a log file exposure, or an infrastructure breach—the attacker has permanent access until someone notices and revokes it. Contrast this with an agent using dynamic, short-lived credentials: even if compromised, the credential expires within minutes or hours, limiting the blast radius dramatically.

This skill addresses the foundational security discipline of managing non-human identities throughout their lifecycle, implementing dynamic credentials, and enforcing least privilege access. Master these principles, and you've built the security foundation for trustworthy autonomous systems.

The Three Sub-Skills of Identity Management

Sub-Skill	Focus Area	Key Concepts
7.1 Service Principals and Identity Lifecycle	Establishing unique agent identities	Service principals, identity lifecycle, federation
7.2 Dynamic, Short-Lived Credentials	Eliminating static secrets	Dynamic secrets, JIT access, credential rotation
7.3 Least Privilege and Scope-Based Access Control	Minimum necessary permissions	OAuth scopes, PBAC, granular access control

7.1 Service Principals and Identity Lifecycle

Every agent must have a unique, verifiable identity that can be authenticated, authorized, and audited. This is the foundation of non-human identity management.

Service Principal Creation and Registration

Core Principle: Each agent is registered as a distinct identity in the organization's identity provider.

A service principal is a non-human identity that represents an application or agent. Unlike user accounts, service principals are designed for programmatic access. Each agent is registered in the identity provider—Azure AD, AWS IAM, Okta, Google Cloud Identity—with a unique identifier, authentication credentials, and metadata describing its purpose.

Technical Implementation:

In Azure AD, use az ad sp create-for-rbac to create a service principal with appropriate role assignments
In AWS, create an IAM role with a trust policy allowing the agent to assume it
In Okta, register the agent as an OAuth client with specific scopes

Benefits: Unique identity enables fine-grained authorization (this specific agent can do X but not Y), complete audit trails (this action was performed by Agent-Invoice-Reader at this time), and the ability to revoke access without affecting other agents.

Identity Lifecycle Management

Core Principle: Managing agent identities from creation to decommissioning.

Agent identities have a lifecycle that must be actively managed:

Creation: Provisioning the service principal with initial credentials and permissions
Active: Normal operation with credential rotation and permission updates
Suspended: Temporarily disabled during incidents or investigations
Decommissioned: Permanently deleted when the agent is retired

Implementation Best Practices:

Use Infrastructure-as-Code (Terraform, Pulumi) to provision and deprovision identities consistently
Implement credential rotation schedules—even for dynamic credentials, rotate the root authentication mechanism regularly
Monitor for orphaned identities—agents that no longer exist but whose identities remain active
Conduct regular access reviews to verify that permissions still match actual needs

Compliance: Essential for SOC2 (access reviews), ISO 27001 (identity management), and regulatory audits that require demonstrating control over all system identities.

Identity Federation and Cross-Domain Trust

Core Principle: Enabling agents to operate across organizational and cloud boundaries.

In multi-cloud or cross-organization scenarios, agents need to authenticate across trust domains. Identity federation uses standards like SAML, OIDC, and OAuth 2.0 to establish trust relationships, allowing an agent authenticated in one domain (e.g., Azure AD) to access resources in another (e.g., AWS).

Workload Identity Federation: Modern cloud platforms support workload identity federation, where agents running in Kubernetes or other container platforms can authenticate to cloud providers without storing credentials. The platform issues OIDC tokens that cloud IAM trusts directly.

Use Cases: Multi-cloud deployments where agents span AWS and Azure, partner integrations where agents from different organizations collaborate, federated enterprise systems with multiple identity providers.

7.2 Dynamic, Short-Lived Credentials

Static API keys are a security liability. Dynamic credentials are generated on-demand and expire automatically, dramatically reducing the blast radius of any compromise.

Dynamic Secret Generation

Core Principle: Credentials are minted on-demand from a secrets management system.

Instead of storing static credentials, agents request temporary credentials from a secrets management system like HashiCorp Vault, AWS Secrets Manager, or Azure Key Vault. The system mints a credential—token, password, certificate—valid for a specific duration (e.g., 1 hour) or single use.

The Flow:

Agent authenticates to the secrets manager using its service principal identity
Secrets manager verifies the identity against the identity provider
Secrets manager issues a time-bound credential for the requested resource
Agent uses the credential to access the target resource
Credential automatically expires after the TTL

Benefits: Eliminates long-lived secrets that can be stolen and used indefinitely. Reduces blast radius—if a credential is compromised, it expires soon. Enables automatic rotation without manual intervention.

Just-in-Time (JIT) Access

Core Principle: High-risk credentials are only issued after explicit approval.

For sensitive operations—production database writes, financial transactions, access to PII—credentials should be issued only after human-in-the-loop authorization. The agent requests access, a human approves (or an automated policy evaluates the context), and the credential is issued for a limited time window.

Implementation Patterns:

Approval workflows: Integrate with PagerDuty, Slack, or custom approval systems
Break-glass procedures: Emergency access paths with enhanced logging and automatic revocation
Time-boxed access: Credentials valid only for the duration of the specific task

Compliance: Required for PCI-DSS (privileged access management), HIPAA (PHI access controls), and high-security environments where all sensitive access must be justified and approved.

Credential Rotation and Revocation

Core Principle: Credentials are automatically rotated and can be instantly revoked.

Even dynamic credentials should be rotated regularly—not just when they expire, but proactively to limit exposure windows. Emergency revocation allows instant invalidation of credentials when a security incident is detected.

Implementation:

Configure automatic rotation schedules in secrets managers
Implement certificate revocation lists (CRLs) for certificate-based authentication
Use token introspection endpoints to validate credentials in real-time
Build revocation capabilities into incident response procedures

7.3 Least Privilege and Scope-Based Access Control

Agents should have the minimum permissions necessary to perform their tasks—nothing more. This limits the damage if an agent is compromised or malfunctions.

Least Privilege Principle

Core Principle: Grant only the permissions required for the agent's specific function.

An agent tasked with reading invoices should have READ access to the invoice table but no WRITE or DELETE permissions, and zero access to unrelated tables like payroll or HR records. This limits the blast radius if the agent is compromised—an attacker can read invoices but can't modify them, delete them, or access other sensitive data.

Implementation Strategies:

Define fine-grained IAM policies (AWS) or RBAC roles (Kubernetes) for each agent function
Use separate service principals for different agent capabilities
Conduct regular permission audits to identify and remove excessive permissions
Implement "deny by default" policies where agents must explicitly be granted access

Scope-Based Access Control

Core Principle: Credentials are issued with explicit scopes defining allowed operations.

Using OAuth 2.0 or similar protocols, tokens are issued with explicit scopes (e.g., calendar.read but not calendar.delete). The resource server validates the token's scopes before allowing access.

How It Works:

Agent requests a token with specific scopes
Authorization server validates the request against the agent's allowed scopes
Token is issued containing only the approved scopes
Resource server inspects the token and enforces scope-based access

This provides defense in depth: even if an agent's token is compromised, the attacker is limited to the scopes embedded in that token.

Policy-Based Access Control (PBAC)

Core Principle: Authorization decisions are made dynamically based on policies and context.

Attribute-Based Access Control (ABAC) and Policy-Based Access Control (PBAC) use policy engines like Open Policy Agent (OPA) or Cedar to make dynamic authorization decisions based on attributes—user role, time of day, resource sensitivity, risk score, geographic location.

Example Policy (in Rego for OPA):

allow {
    input.agent.role == "invoice-reader"
    input.action == "read"
    input.resource.type == "invoice"
    input.time.hour >= 9
    input.time.hour <= 17
}

This policy allows invoice readers to read invoices only during business hours—a dynamic constraint that static permissions can't express.

Real-World Security Scenarios

Incident: Static API Key Leak

Scenario: Developer commits AWS access keys to a public GitHub repository.

Impact: Within hours, attackers use the keys to spin up cryptocurrency mining instances. $50,000 bill before anyone notices.

Root Cause: Static, long-lived credentials with excessive permissions stored in code.

Mitigation: Implement dynamic credentials from AWS Secrets Manager. Apply least privilege IAM policies. Use git pre-commit hooks to scan for secrets. Enable AWS cost anomaly detection.

Incident: Compromised Agent Lateral Movement

Scenario: Customer service agent is compromised through prompt injection. The attacker uses the agent's credentials to access the payroll database.

Impact: Data breach exposing employee PII, regulatory fines, reputational damage, mandatory breach notifications.

Root Cause: Over-privileged agent—customer service agent had access to payroll system it didn't need.

Mitigation: Implement granular RBAC limiting each agent to its specific function. Use behavioral analytics to detect anomalous access patterns. Segment networks to prevent lateral movement.

Success: Zero-Trust Agent Architecture

Scenario: Financial services firm implements comprehensive non-human identity management for all AI agents.

Implementation: Istio service mesh with mTLS for agent-to-agent communication. Short-lived certificates from HashiCorp Vault. OPA for policy-based authorization. Behavioral analytics for anomaly detection.

Outcome: Passed security audit with zero findings. Penetration test showed no lateral movement possible—compromised agents were contained to their specific scope.

The Principle-Based Transformation

From Static Credentials...

Embedding API keys in code
Long-lived credentials stored in config files
Shared credentials across multiple agents
No audit trails or identity attribution

To Dynamic Non-Human Identity...

Understanding identity as a first-class security primitive
Mastering cryptographic authentication and authorization protocols
Applying zero-trust principles to non-human actors
Implementing dynamic, short-lived credentials with full auditability

Transferable Competencies

Mastering non-human identity management builds expertise in:

Identity and Access Management (IAM): Authentication, authorization, identity lifecycle management
Cryptography: Public key infrastructure, certificates, tokens, digital signatures
Security Protocols: OAuth 2.0, OIDC, SAML, mutual TLS
Secrets Management: Vault, key management systems, credential rotation strategies
Policy Engineering: ABAC, RBAC, policy languages (Rego, Cedar)
Zero-Trust Architecture: Continuous verification, least privilege, assume breach mentality

Common Pitfalls to Avoid

Static API keys: Embedding long-lived credentials in code or config files
Shared credentials: Multiple agents using the same identity—impossible to audit
Over-privileged agents: Granting more permissions than necessary
No credential rotation: Credentials that never expire or rotate
Weak authentication: Using passwords instead of certificates or tokens
No audit trails: Unable to attribute actions to specific agent identities
Ignoring lifecycle: Not decommissioning retired agent identities
No revocation capability: Unable to instantly revoke compromised credentials
Cross-domain trust failures: Improper federation configuration

Implementation Guidance

For Security Architects: Design service principal architecture for all agents. Select identity provider and secrets management platform. Define credential lifecycle policies. Implement least privilege and scope-based access control. Design cross-domain federation for multi-cloud environments.

For Developers: Register each agent as a unique service principal. Implement dynamic credential retrieval from secrets manager. Use OAuth 2.0 scopes for fine-grained authorization. Add comprehensive audit logging for all agent actions.

For Security Operations: Monitor for anomalous agent behavior using behavioral analytics. Conduct regular permission audits. Implement automated credential rotation. Establish incident response procedures for compromised agents.

Looking Forward

The field is evolving toward:

Decentralized Identity (DID): Blockchain-based agent identities for cross-organization trust
Continuous Authentication: Real-time verification of agent identity and behavior, not just at login
AI-Powered Threat Detection: ML models that detect compromised agents through behavioral analysis
Quantum-Resistant Cryptography: Preparing authentication protocols for post-quantum security
Verifiable Credentials: Cryptographically verifiable claims about agent capabilities and permissions

Next Skill: Tool Engineering — Designing the tools that extend agent capabilities.

Back to: The Nine Skills Framework | Learn

Subscribe to the Newsletter → for weekly insights on building production-ready AI systems.