Latest / TeqTalk with Jas / Agent Gateway Explained: How Enterprises Control AI Agent Actions
Transcript
- Ep75 Intro: Agentic systems can s can access sensitive information, it can execute code, and it can communicate externally. Imagine your company has an AI agent that reviews supply invoices, checks payment details, and prepares transactions for approval. One morning the agent receives an email from a supplier with an attached invoice. Hidden inside that document is an instruction telling the agent to change the supplier's bank account information before actually preparing the payment. The employee never requested this change, but the agent reads the document and potentially interprets that hidden instruction as something it should execute. I have an example of external data coming with some hidden malicious instructions. Here, I have an email open and it's requesting a quote for a replacement roof. What you don't see is that this email has additional text with white font on a white background. Only when I highlight it, you'll see that it includes additional instructions asking for internal information as an attempt to exfiltrate data. This is called as an indirect prompt injection attack. It is a situation where malicious instructions are placed inside information that an AI agent is supposed to read, such as an email, document, website, or database record. The attacker is trying to turn ordinary data into instructions that influence the agent's behavior. So prompt injection is about hijacking the large language model. giving it what looks like new instructions and basically taking over the prompt. Now here is the real problem. The agent might already have legitimate access to the supplier management system. Its credentials are valid. The API is functioning normally. So what prevents the agent from changing the bank account? I mean, just think we need to get better at controlling these models. What if there were a control layer that could inspect suspicious content, determine which actions the agent is permitted to perform, and block an unauthorized change before it actually reaches the business system? This is one of the important problems that agent gateway architectures are emerging to solve. And that is what we are exploring today on Tech Talk. We will look at how enterprises operated before AI agents. What has fundamentally changed the six key capabilities of an agent gateway? How can it contain attacks like prompt injection and some of the most interesting enterprise developments and research happening in 2026? Well, let's go back a few years. Imagine an employee submitting an expense reimbursement. They uploaded a receipt, an expense system checks the company policies, sends the report to manager for approval, and then a finance processes the payment. Follows an established workflow. Developers and business teams define the rules and approvals and integration between the systems. And we already have the mature technology stack supporting this. Integration platforms such as NewSort, Boomi, Vocato, Connect applications, API gateways manage API traffic, authentication and routing. Identity systems manage access permissions. Workflow engines such as those in ServiceNow and other business platforms manage business process execution. Security system monitors activities and applications maintain audit records. These are not outdated technologies. They are essential, very much important, and they remain relevant even in an agentic architecture. But the important thing is that the application normally follows a workflow somebody has designed in advance. When we introduce AI agents, the assumption begins to change. Now let's take the same example of expense reimbursement. But this time, imagine we introduce an AI agent. So instead of An employee going through multiple applications, collecting resets, filling out the forms, and submitting expenses manually, they simply tell an AI agent that hey, I traveled to New York last week, can you find all my expenses? Check them against company policy and submit my reimbursement. Sounds pretty straightforward, right? But think about what the agent actually needs to do behind the scenes. First, it needs access to employees, Gmail, or Outlook to find hotel confirmations. Flight tickets and restaurants. Then it might connect to your Google Drive or SharePoint to retrieve any stored results. Next, it needs to access the company's travel and expense policy, which might be stored in any SharePoint or any internal knowledge system. Then it needs to connect to an expense management application such as your SAP, Concrere, or Workday Expenses to create expense report, attach a receipt, and submit it for approval. So we are talking about one agent potentially interacting with four or five different enterprise applications just to complete one employee's request. Now, here is what things are getting interesting. In our traditional automation model, developers would have predefined the application to call in what sequence and under what conditions. But with an AI agent, we give it the objective, and the agent can figure out which tools to use and in what sequence. Maybe the hotel reset is missing from the So it searches the document repository. Maybe the mail expense exceeds the company policy, so it flags that expense before submitting the claim. And how does that agent connect to these systems? Well, through APIs, enterprise connectors, and increasingly MCP, which is Model Context Protocol, which gives compatible AI agents a standardized way to discover and use external tools. But here is the challenge. This agent now has access to email, documents. Financial information and an application where it can submit the transaction. What if it accesses information it wasn't supposed to? What if it uses a wrong tool? What if someone places a malicious instruction inside an email or receipt and the agent follows it? Well the last example is called the prompt injection. And there is another important security concept called as excessive agency where an AI agent is given more permissions. Or authority than it actually needs to complete a task. So this is where our traditional integration and security architecture needs an additional control because the question is no longer just whether the agent can connect to these applications, the question is more towards what exactly should the agent be allowed to do once it has connected. And that is where the agent gateway comes into the picture. Now, what exactly is an agent gateway? Well, An agent gateway is a managed control layer between AI agents and capabilities they use, including your enterprise applications, APIs, MCP servers, databases, and other agents. Now think of it as a checkpoint between what an agent wants to do and what an enterprise allows it to do. It can provide access to approved tools, manage authentication, check permissions, apply security policies, and record the actions that pass through it. Is this simply another integration platform? Well, not exactly. An integration platform focuses on connecting systems and moving data or executing integrations. An API gateway traditionally focuses on managing API communication. A model gateway manages how applications interact with AI models. However, an agent gateway adds control around the tools and actions that AI agents use to perform the task. Some products combine these responsibilities. In fact, AEWS now documents agent core gateway as supporting agent-to-tool, agent-to-agent, and model traffic through a common gateway architecture. So we shouldn't think of these as mutually exclusive product categories. The important architectural principle is that the AI model can propose an action, but an independently enforced policy should determine whether that action is allowed. Here are the six capabilities of an enterprise agent gateway. The first capability is integration and connectivity. Well, an agent needs to communicate with different platforms like Salesforce, Workdays app, email databases, and other business applications. The gateway can provide a centralized access point to approved APIs, MCP servers, and enterprise tools. This reduces the need for every agent team to create its own connectivity and credential management approach. Well, the second is tool discovery and management. Imagine an enterprise with hundreds of applications and thousands of available actions. An agent reviewing travel experience doesn't need access to every other tool in the organization. The gateway can provide an approved tool catalog and restrict which capabilities are available to each agent. So this can also improve efficiency by avoiding the need to load unnecessary tool descriptions into the model context. The third capability is identity and authorization. Suppose Sarah from Finance asks an AI agent to prepare a monthly report. We need to identify Sarah, the agent executing the work, and the permission under which downstream application is accessed. So Sarah might personally have permissions to modify financial records, but her reporting agent should not automatically inherit every one of those privileges. Well, this is where delegated identity, agent identity, least privilege access become so important. The fourth is security and policy enforcement. Before an agent modifies a customer record, sends sensitive information, or initiates a transaction, the gateway can evaluate the operation against enterprise policies. For example, a customer service agent may be allowed to view and order and issue refunds up to an approved limit, but refunds above that threshold require escalation. Some gateways can also integrate content. inspection to detect suspicious tool responses or possible prompt injection attempts. Well the fifth is execution control and human approval. Not every business activity carries the same level of risk. Reading a company policy may happen automatically, while changing supplier payment detail should require stronger controls. A gateway can reject unauthorized actions or integrate with an approval workflow. It may also enforce limits on tool usage and provide mechanisms to revoke access when necessary. The sixth is observability, auditing and compliance. Organizations need to know which agent called which tool, on whose behalf, what operation was attempted and whether it was approved or denied. Those records support security investigations, compliant evidence, operational monitoring and accountability. Together these six capabilities make the agent gateway significantly more than just an integration bill. One important clarification Not every agent gateway product implements all six capabilities natively. Some rely on external identity providers, policy engines, security products, or approval systems. The enterprise architecture matters more than how a vendor packages the product. Now let's come back to the supplier invoice from our opening example, because this is where the architecture becomes very practical. Remember, the employer asked the AI agent to review the invoice, but the document contained a malicious instruction to change the supplier's bank account. There are several points where an appropriately designed agent gateway architecture can intervene. So the first is before the malicious information actually reaches the model. When the agent retrieves an invoice or an email through a tool, a security inspection layer can examine the response for suspicious instructions. If it detects potential prompt injection, it may block the response, flag it for investigation, or remove suspicious content. However, this detection isn't perfect. Attackers can disguise instructions and legitimate documents can sometimes resemble instructions. That's why we need another protection mechanism. The second is at the tool permission level. Suppose our agent ignores the warning and attempts to call a tool named update supplier bank account. The gateway can check whether this agent is authorized to call the tool. And if the permission only allows it to retrieve the invoices and review supplier records, The gateway denies the request. The agent may believe the bank account update is necessary, but that doesn't grant it permission to perform the operation. So the third is at the policy level. What if the agent has legitimate permission to update supply information, but not bank account feeds? A more granular policy can examine a requested operation and prevent modifications to those sensitive feeds. And the fourth, of course, is a human approval. Even if an agent is permitted to initiate a bank account change, the organizations can require a separate verified process before that change takes effect. And finally, the attempted action and policy decisions are recorded for security monitoring and investigation. Notice that we are not relying on a single security mechanism. We are combining suspicious content detection, tool restrictions, action level policies, independent approval and auditability. The strongest part of this design is that even when the model is manipulated, a deterministic policy can still block an action that falls outside its authorization. But there is an important limitation. The gateway must actually intercept the relevant execution path. If an agent can bypass it or has unrestricted credentials to access the application directly, those gateway controls may not protect that action. And if a harmful action is technically permitted by policy, the gateway won't necessarily Recognize the underlying business decision as inappropriate. So the objective isn't to claim that Agent Gateway eliminates prompt injection. The objective is to prevent successful manipulation of the model from automatically becoming a damaging business action. Now let's look at what actually is happening in 2026 because companies have already started building these capabilities. AWS, through Amazon Bedrock, Agent Core Gateway is bringing tool connectivity and policy enforcement together. It's also integrating security controls that can help detect prompt injection and restrict unauthorized actions. Microsoft, with Agent 365 Tooling Gateway, is focusing on identity and access. The idea is simple. An AI agent should only access tools and data. It's authorized to use, ideally under the appropriate employees permission. Cloudfair launched its MCP server portals in September 2026. Allowing enterprises to centrally manage approved MCP connections, monitor activity, and apply data protection controls. And stack one is combining enterprise connectors with granular tool permissions and prompt injection detections through its defender technology. Now here is a real-world example I find particularly interesting. In October 2026, PayPal shared details of its internal MCP hub, reporting over 2000 tools across 175 certified MCP servers. By helping agents discover only the tools they need, PayPal reported approximately 99% less tool schema context in its comparison. And on the research side, a 2026 paper called Shield MCP reported reducing indirect prompt injection attacks success from 47% to below 6% in its experimental evaluation. That's a research result, not a guarantee for production systems. So, when you look at these developments, there is one common direction. And it's that enterprises are moving beyond simply connecting AI agents to applications. They're building the identity, they're building security, they're building execution controls needed to trust what those agents actually do. So, does every enterprise need an agent gateway? Well, my view is that every enterprise deploying agents across multiple business systems will eventually need these governance capabilities. But that doesn't necessarily mean that every company needs to purchase a separate gateway product. And if you're running one agent that reads a few approved documents, your existing platform controls may be sufficient. But when you have agents interacting with finance, HR, sales, customer service, and external partners managing every connection and every permission independently becomes increasingly difficult. So I would recommend three starting points. Know your agents and tools. Identify which agents are operating, which applications they access, which MCP servers they use, and what actions they can perform. Second, establish clear execution policies. Decide which actions can happen automatically, which require approval and which should never be available to a particular agent. These rules really need to be enforced by systems outside the model wherever it is possible. Third, test the controls continuously. Do not test only whether an agent can successfully complete a task, test whether it can be manipulated through a document, whether it can call an unauthorized tool, and whether the organization can detect and stop a harmful action. And when it comes to compliance, remember that audit locks alone aren't enough. Organizations need appropriate data handling practices, identity governance, retention controls, document approvals, monitoring, and evidences that Their policies are actually being enforced. A gateway can help provide those capabilities, but it doesn't automatically make an enterprise compliant. So we spent years connecting applications through APIs and integrations, and then we developed sophisticated ways to manage identity access security. Now we are entering a world where AI agents can decide which tool to use and what action to take. And the question is moreover: should this particular AI agent be allowed to take? This particular action for this particular user under these circumstances. That is why agent gateway capabilities are becoming so important. I believe the future of Enterprise AI isn't about giving agents unlimited autonomy, it's about giving them enough autonomy to create business values with the controls needed to maintain trust, security, and accountability. I'm Jess Carr and this is Tech Talk. If you found this conversation valuable, subscribe for more insights on AI enterprise architecture and technologies transforming how organizations operate. I'll see you in the next episode.