How Axiom Standardized Security Across a Growing Fleet of AI Agents

Outgrowing Custom Controls

Axiom's first production agents were secured largely within the workflows themselves. Each team determined which credentials an agent needed, which services it could call, and which restrictions should be enforced before particular actions were executed. This approach worked while the number of agents remained small and the systems they interacted with were limited. As adoption grew, however, the same pattern began creating operational complexity. Different teams implemented permissions in different ways, similar access rules were duplicated across multiple workflows, and changing a security requirement often meant finding every place where that decision had been encoded. The infrastructure team could see that continuing along the same path would eventually produce a fragmented collection of authorization mechanisms that would be difficult to understand, maintain, or audit.

Axiom's challenge became even more pronounced because its agents were not identical. Some were built with different frameworks, others used different models, and many interacted with completely different parts of the company's infrastructure. The security model could not depend on a particular agent technology if it was going to remain useful as the stack evolved. Axiom wanted a consistent way to describe identity and permissions regardless of how an agent had been implemented. The team also needed a model that could accommodate growth. Adding another hundred agents should not mean adding another hundred independent approaches to authentication, authorization, and logging. Security needed to become shared infrastructure that every autonomous system could rely on rather than functionality repeatedly rebuilt inside each deployment.

Standardizing Agent Security

Axiom adopted Vantor to establish a common control layer across its agent environment. Individual agents received verifiable identities, while permissions were expressed through policies that defined which resources and actions were available to them. Because these rules existed outside the agents themselves, the same security model could be applied across different frameworks, services, and deployment environments. An agent responsible for internal research could be given broad read access while remaining unable to modify resources. An operational agent could receive more specific write permissions limited to the systems required for its workflow. The infrastructure team could reason about both agents through the same set of concepts even though their underlying implementations might have little in common.

Moving authorization into Vantor also reduced duplicated work across engineering teams. Developers no longer needed to design a complete access system every time they introduced a new agent or connected an existing workflow to another internal service. They could build against established identities and policies, reuse permission patterns that already existed, and request narrowly scoped exceptions when a new capability required them. Security changes could also be introduced centrally rather than coordinated across dozens of codebases. If a resource became more sensitive or a particular class of action required tighter controls, policies could be updated without asking every team to independently reproduce the same change. Vantor turned authorization from a workflow specific implementation detail into part of Axiom's shared infrastructure.

Growing Without Policy Sprawl

As Axiom expanded its fleet of agents, the benefits of having one policy layer became increasingly visible. New agents could inherit existing patterns instead of starting from an empty security model, while teams could still define precise permissions for specialized workflows. Administrators had a clearer view of how access was structured across the organization and could identify unnecessary permissions before they became permanent. The company could also introduce additional systems without creating an entirely separate authorization architecture for each integration. What had previously threatened to become a growing network of custom rules could instead be managed as one coherent set of identities, resources, actions, and policies.

The centralized activity trail gave Axiom the other half of that model: visibility into how those permissions were actually being used. The infrastructure team could review requests across agents, identify recurring denials, understand which resources were being accessed most frequently, and trace individual actions back to the agent and policy responsible for them. This made it possible to refine permissions based on real behavior rather than leaving broad access in place simply because it was easier. As Axiom continued increasing the autonomy of its systems, it did not have to accept decreasing visibility as a consequence. Vantor gave the company a security foundation capable of expanding with its agent infrastructure while keeping access understandable, enforceable, and accountable.