MCP-Connected AI Agents Push Engineering Teams To Build A New Enterprise Trust Layer

AI agents now carry more operational privilege than any prior category of enterprise software. They read and write to databases, execute system commands, browse the web, call external APIs, and act on instructions that may include poisoned context from untrusted sources. The protocol layer connecting them to those capabilities—MCP—ships without native security controls. And most engineering teams, under pressure to ship fast, are granting that access without building the defensive layers to constrain it.

Ankush Rai is a Software Engineer at the all-in-one retail system Allyvia who previously built production systems at ZS and EY across healthcare, clinical analytics, and enterprise platforms. He developed Argus, an open-source agent security framework that implements three defensive layers to intercept, analyze, and control agent behavior across MCP-connected systems. His perspective comes from building in this space and encountering the failure modes directly.

"The agents are so much more integrated into your software than you yourself have provided them access," Rai says. "The question of how much access they have and how much they need input from humans matters a lot. That's where the gap comes in."

The trust layer is missing

Rai frames the problem with an analogy: MCP is to agents what HTTP was to the web. What is missing is the equivalent of TLS. "You just can't go to any website on the web without a trusted layer that tells you the site is secure," he says. "MCP is like that. You need a layer, and it doesn't exist yet." The result is that agents trust input and output by default, and any unfiltered prompt or data response can trigger execution of commands the developer never intended.

"When we were developing Argus, it got very clear that it's very easy to inject prompts because the layer currently trusts too much," Rai says. "If you're not putting any guardrails in place, the agent will just execute any command."

The defensive pattern emerging is a bidirectional proxy that sits between the agent and every system it touches, intercepting both requests and responses. If the agent has been compromised or is acting on poisoned instructions, the proxy layer analyzes the command before it reaches production systems and blocks anything that violates predefined rules.

Delegate before you defend

Rai argues that the guardrail layer itself is not sufficient if agents start with unconstrained access. The more effective pattern is restricting what each agent can do before it ever reaches the defensive layer. In Argus, the third internal layer uses JWT tokens to define which tools each agent is authorized to call. If an agent is not authorized for web access or database writes, the system blocks the request before the guardrail even evaluates it.

"One of the biggest blind spots is not making your agents delegate certain responsibilities," Rai says. "Your agents should have only a set number of responsibilities and exposure to a set number of tools. Otherwise they'll hallucinate, and there won't be any guardrails. They'll just do anything."

That pre-guardrail scoping reduces latency as well: the system does not need to analyze a request that the agent was never authorized to make. It is the agent-level equivalent of least privilege, applied before the firewall rather than after.

This will not be fully solved

Rai is direct about the limits. "Stopping these attacks 100% is not possible," he says. "Think about the web itself. We have so many cybersecurity companies, but there are still attacks. These prompts are going to evolve and smart people are going to find a way."

He points to Anthropic's own source code exposure as evidence that even organizations building the frontier models cannot fully secure their own systems. "The company that has been part of the revolution was not able to secure their application to a level that they didn't expose their whole code on a public repo," Rai says. "You can see how much work is still needed."

What makes agentic security different from traditional infrastructure security is that the threat is not just about who has access to the database. It is about who can influence the agent's interpretation of that database. "We just can't depend on cloud security or closed internal systems," Rai says. "We need a system that understands how agents move, what role an agent plays in the loop, and that can protect the application based on that understanding."

For engineering teams building on composable stacks where agents read, write, and reason across connected systems, the mindset shift is overdue. "Even though we are building things fast, you have to think from the defensive point of view," Rai says. "You just can't automate everything. You have to be part of the process."