Terraforming Access: Why Auth Needs to Be Defined in Code
Jun 14, 2025
2 mins
Matt (Co-Founder and CEO)
In the world of infrastructure, the concept of "Infrastructure as Code" (IaC) has revolutionized how we provision, manage, and scale resources. Tools like Terraform, CloudFormation, and Ansible allow us to define our environments in version-controlled, human-readable code, enabling consistency, repeatability, and peer review.
As we grapple with the complexities of managing autonomous AI agents and their dynamic identities, it's becoming abundantly clear that "Access as Code" (AaC) is not just a nice-to-have, but a critical necessity. Especially for agent identity, relying on traditional, manual, or GUI-based role management systems is a recipe for insecurity, inconsistency, and unmanageable complexity.
The Limitations of Traditional Access Management for Agent Identity:
Manual Configuration is Error-Prone and Slow:
Defining permissions for hundreds or thousands of ephemeral agent identities through GUIs or manual scripts is simply not scalable. It introduces human error, inconsistencies, and significant delays.
For dynamic agent identities that change scope or lifespan, manual updates are impossible.
Lack of Version Control and Audit Trails:
When access policies are configured through clicks, there's no inherent version history. It's difficult to see who made what change when, and to roll back to a previous state.
This is especially problematic for agents, where understanding the exact identity configuration at the time of an incident is crucial for forensics.
Inconsistent Deployments:
Different environments (dev, staging, production) often end up with slightly different access policies due to manual configuration drift. This leads to "works on my machine" issues and security gaps when agents move between environments.
Poor Visibility and Reviewability:
It's hard to get a holistic view of all permissions granted across your system without a centralized, code-defined source of truth.
Security reviews become arduous, as there's no easy way for peer review or automated checks on access policies.
Traditional RBAC Can't Keep Up with Granularity:
Role-Based Access Control (RBAC) is great for human roles (e.g., "Developer," "Admin"). But for agents that need highly granular, context-dependent permissions (e.g., "read this specific S3 object only for 30 seconds, on behalf of user X, as part of workflow Y"), RBAC often becomes too coarse-grained or leads to an explosion of roles.
Terraforming Access: What "Access as Code" Means for Agents
For agent identity, "Access as Code" means:
Declarative Policy Definition: Instead of imperatively granting permissions, you declare the desired state of an agent's access in a structured, human-readable format (e.g., YAML, HCL).
Version Control: All agent identity policies are stored in a Git repository. This means full history, diffing, branching, and merging capabilities.
Automated Enforcement: Tools (like policy engines or infrastructure automation platforms) consume these code-defined policies and automatically provision or update the agent identities and their permissions.
Peer Review and Approval Workflows: Just like code, access policies can be reviewed by security and engineering teams before being applied, reducing the risk of misconfigurations.
Automated Testing: Policies can be tested as part of CI/CD pipelines to ensure they meet security requirements and don't break existing functionality.
Dynamic Policy Generation: For highly ephemeral agents, the "code" might not just be static files but logic that dynamically generates short-lived, scoped identities based on run-time context.
An Example: Agent Identity Defined in HCL (Terraform-like)

This code snippet illustrates how an agent's identity, its allowed origins, its delegation capabilities, and its specific access policies can be declared programmatically. This brings the same rigor and security benefits of IaC to the critical domain of access management for autonomous agents.
Without treating agent identity as code, organizations will find themselves drowning in manual configuration, facing auditability nightmares, and struggling to maintain a secure posture in the fast-evolving landscape of autonomous systems. Terraforming access is no longer optional; it's foundational for the secure scaling of AI.