How Meridian Gave AI Agents Access to Sensitive Systems With Clear Boundaries

Protecting Sensitive Infrastructure

Meridian began introducing AI agents into operational workflows where employees previously moved between several internal tools to investigate transactions, review account information, and complete routine financial processes. Agents offered the potential to reduce repetitive work significantly, but their usefulness depended on being able to interact with systems containing sensitive customer, payment, and operational data. For Meridian's security team, simply giving an agent the same credentials as an existing application or employee was not acceptable. Autonomous systems could make decisions and execute actions at a speed and frequency that made overly broad access particularly risky. As agent capabilities increased, Meridian needed stronger guarantees about which identity was acting, what it could reach, and which operations it could perform once access was granted.

The company also wanted to avoid treating AI security as a collection of isolated safeguards built separately into every new workflow. Different agents were being developed by different teams, connected to different systems, and given different levels of autonomy. Without a shared security layer, the organization risked accumulating a mixture of credentials, custom authorization logic, and undocumented exceptions that would become increasingly difficult to review. Meridian needed a way to define explicit boundaries around each agent without preventing teams from continuing to experiment and deploy. Those boundaries had to remain visible to security teams and enforceable in real time, particularly when an agent attempted to interact with financial systems where a single inappropriate action could have consequences far beyond the workflow itself.

Defining Precise Boundaries

Using Vantor, Meridian moved agent permissions into a centralized policy layer. Every agent could be assigned an identity and a narrowly defined set of capabilities based on its actual role. A reconciliation agent, for example, could be permitted to read transaction records and compare account information while remaining unable to modify payment instructions or access administrative controls. Another agent could be allowed to update specific operational records while being denied access to customer credentials or treasury systems. These distinctions could be expressed at the level of individual resources and actions rather than through broad application level access. When an agent made a request, Vantor evaluated the identity, requested resource, action, and applicable policies before allowing the request to proceed.

This approach gave Meridian control without requiring security logic to be embedded throughout each autonomous workflow. Policies could be adjusted centrally as an agent's responsibilities changed, and permissions could be narrowed or revoked without changing the agent's underlying model or orchestration framework. The security team could establish organization wide rules while still allowing individual teams to define more specific access requirements for their own use cases. Vantor also made those boundaries easier to inspect because permissions were expressed consistently rather than scattered across service configurations and custom code. As Meridian added new agents, it could extend an existing security model instead of creating another independent set of controls every time a new autonomous workflow reached production.

Making Every Decision Traceable

For Meridian, enforcement was only one part of the requirement. The company also needed to understand what agents were doing after they were deployed. Vantor recorded each access request along with the agent identity, requested action, affected resource, policy decision, and resulting outcome. That meant security teams could trace activity without piecing together information from multiple application logs or trying to infer which shared credential had been responsible. If an action was denied, they could immediately see which rule prevented it. If an action was allowed, they could identify the policy that authorized the request and the context in which the decision had been made.

That level of traceability made autonomous systems easier for Meridian to govern as they became involved in more sensitive workflows. Reviews could focus on a clear history of agent behavior rather than assumptions about how permissions should have worked. Security teams could investigate unusual activity, verify that agents remained within their intended scope, and identify policies that needed to be tightened as workflows evolved. Just as importantly, engineering teams gained a clearer understanding of why requests succeeded or failed, reducing the friction between security requirements and product development. Vantor allowed Meridian to increase the practical capabilities of its AI agents while preserving the level of accountability expected from the rest of its financial infrastructure.