AI agents aren’t a software-engineering-only project anymore. In a recent meshIQ webinar, Greg described a customer whose CEO asked every employee to look at how they could build their own agents. That’s the pace we’re seeing: not one or two agents per company, but potentially thousands, built by teams across the business on whatever framework suits them.
That changes what governance has to do. Once software can act on someone’s behalf, whether it’s issuing a refund, updating a record, or calling an API, seeing what it did afterward isn’t enough. You need control while it’s running. In our recent webinar, Greg Deakyne, President of Product Management, and Gourab Basu, VP of Engineering, discussed how we approached this challenge with AgentIQ™.
Watch our On-Demand Webinar
In this meshIQ webinar, we explore what governing autonomous AI agents actually takes and how AgentIQ™ brings governance directly into the agent execution flow.
Why does it matter where governance sits?
There are two basic ways to govern an agent. The first is a gateway: a layer between the agent and whatever it talks to, whether that’s an LLM or an enterprise system. The second is what we built, which is in-flow governance. The AgentIQ™ SDK runs inside the agent’s own execution flow. The gateway approach has a coverage problem. An agent can reach tools through an MCP server, a direct HTTP call, a native SDK or a local function. A gateway only governs the traffic you’ve routed through it, so any path you forgot to configure is a path you’re not governing. With AgentIQ™ operating inside the agent’s execution flow, tool calls can be governed consistently, whether they’re made through an MCP server, direct HTTP call, or native SDK.
Being in-flow also unlocks three things a gateway struggles with:
- Pausing the agent for a person. For human-in-the-loop to work, the agent needs to stop and wait for a decision, then pick up where it left off. A gateway can see the request go by, but it can’t easily pause the agent’s execution.
- Execution controls. Iteration limits, token limits and stopping a runaway agent all need access to the agent’s loop.
- One trace. Because governance runs alongside the agent, you get a single trace of what the agent tried to do, which policies fired and who approved what.
The trade-off is that one SDK can’t plug into every framework, because each framework handles interception differently. So we build framework-specific support. AgentIQ™ currently supports LangGraph, the OpenAI Agents SDK, CrewAI, AWS Strands, and Google Agent Development Kit (ADK), with support for additional frameworks planned.
How do you write policies for a system that builds its own workflow?
With a traditional deterministic workflow, you design the path and its controls up front. Agents don’t work that way. They’re non-deterministic and build their workflow as they go, choosing tools along the way. You can’t predefine every path.
What you can govern is the handoff, the moment the agent calls a tool. And at that point, a simple allow-or-block choice throws away the main reason you built an agent. If every risky action is blocked, your agents end up limited to read-only use cases.
So AgentIQ™ decides based on the values in each call. Take a refund agent:
- Under $50, it acts on its own.
- Around $1,500, it asks whoever is using the agent to confirm.
- $5,000 or more needs a supervisor’s approval, much like an approval step in a classic workflow.
- Some requests are denied outright.
The four outcomes are Allow, Confirm, Escalate and Deny. Policies live centrally on the AgentIQ™ server, not in the agent’s code. When an agent attaches to AgentIQ™, the console pre-populates the parameters of all its tools. Whoever owns compliance can then build rules by dragging those parameters into conditions at design time. Every decision, policy and approval goes into the unified trace.
How do you handle prompt injection and off-limits topics?
When a prompt comes in, AgentIQ™ can pause execution, run the prompt through its own analysis and return a confidence score for how likely it is to be a prompt injection. The confidence score can then trigger different policy responses. For example, using illustrative thresholds:
- Above 0.8: deny.
- Between 0.5 and 0.8: you’re not sure, so send it to a person for review.
- Low scores: allow.
These policies can be set per agent or globally. A global zero-trust policy applies automatically to any agent from the moment it registers with AgentIQ™, so new agents don’t start ungoverned.
Topics work the same way. You can blocklist subjects you never want an agent to touch, such as politics or religion, or allowlist the only subjects an agent should handle. This helps define the topics an agent is permitted to address. You can also add deterministic blocks, like banned phrases or rejecting code snippets as input. That matters because agents with system access have broken out of sandboxes by executing code.
How do you mask PII without breaking the agent?
This was one of the biggest concerns we heard from customers. Once data goes into a model, you lose visibility into what happens to it, and few enterprises are comfortable handing card numbers or personal details to a third party.
AgentIQ™ masks sensitive data before every LLM call, and again before the agent sends its response to the user. Standard patterns like Social Security and credit card numbers are predefined, and each enterprise can configure what else counts as sensitive.
What AgentIQ™ doesn’t mask is the data going to the system of record. When the agent’s tool call reaches the system that actually needs the real value to complete the transaction, the real value passes through. This allows sensitive information to be masked before reaching the model or appearing in the agent’s response, while the system of record still receives the information needed to complete the transaction.
What does governance cost, and how do you stop a runaway agent?
On direct cost, AgentIQ™ makes no LLM calls of its own. Its decisions use built-in capabilities, so it doesn’t add to your model bill.
The bigger cost risk is the agent itself. With a deterministic workflow, you know the path, so you roughly know the cost. With an agent, nobody designed the path. If an agent gets stuck in repeated loops or unnecessary tool calls, the resulting costs may only become apparent when the model provider’s bill arrives.
AgentIQ™ has two controls for this:
- Iteration limits. If you know a use case shouldn’t need more than 10 iterations, anything past that probably means something’s wrong. It works like a stop-loss.
- Token limits. An agent can blow through tokens even with few iterations, especially if tools return large amounts of data that get sent to the model.
The more complex the workflow, the more these matter. It’s also a shift in FinOps thinking: from “what are we spending on this model?” to “what is this specific agent costing us, and what is it producing?”
What does an auditor actually get?
When someone asks what an agent did, why, and who approved it, AgentIQ™ gives a trace down to the individual action. It shows:
- what the user entered
- which tools the agent accessed and with what permissions
- what it sent to the LLM
- each back-and-forth along the way
It’s readable in the UI and backed by a data store you can export for an auditor. The same detail helps developers when someone inevitably asks how to make the agent faster or cheaper. It also reduces the need to piece together execution records from different models, frameworks, and providers.
Where should teams start?
Gourab’s advice: observability and governance can’t be an afterthought you bolt on before production. Build them in alongside the agent from the start. These systems are powerful and non-deterministic, and that combination needs control from day one.
Greg’s advice: the models, tools and endpoints your agent uses will change within weeks of you building it. At a minimum, start with something that shows you every trace and action, so you can spot when an agent starts doing things you didn’t plan for. When you move to production, go zero trust. Define what the agent is allowed to do, and everything else either stops or goes to a person for approval. The conversation around enterprise AI is shifting from what AI can generate to what AI is allowed to do. Getting that right means agents with enough autonomy to be useful, without giving up visibility, security or control. If you’d like to see how AgentIQ™ handles the agents you’re already building, contact us at hello@meshiq.com.