AgentIQ is meshIQ’s governance control plane for enterprise AI agents. It discovers every agent running across an organization, including the ones nobody registered, governs what each agent is allowed to do down to the exact parameters of an action, and keeps a replayable audit trail of everything an agent actually did. Unlike most AI governance tools, which sit outside an agent and watch its calls to a model or a database from a distance, AgentIQ’s SDK runs inside the agent’s own execution flow. This is an architectural choice: governing in-flow instead of from a gateway, and what separates AgentIQ from other architectural choices.
The problem: enterprises are running AI agents they cannot see or control
Every enterprise experimenting with AI agents right now has more of them than anyone has actually counted. Agents get built by different teams, on different frameworks, for different purposes, and they accumulate the same way shadow IT always has: quietly, and faster than anyone expected.
That would be a manageable inconvenience if agents only read data. They do not. A modern AI agent holds credentials, calls tools, moves money, edits records, and increasingly makes decisions that used to require a human in the loop. Each of those capabilities is a form of access, and access that nobody is tracking is exposure, whether or not anyone has measured it yet.
Three specific gaps show up over and over in enterprise environments:
Shadow agents. Agents deployed outside any registered inventory, invisible to whatever governance tooling already exists, until something goes wrong and someone has to reconstruct what happened after the fact.
Credential sprawl. Every tool an agent calls is effectively a credential it holds. Most of those tool grants were never reviewed with that framing in mind, and almost nobody is tracking how they accumulate over time as an agent’s toolset grows.
Compliance exposure. Frameworks like the EU AI Act and the NIST AI Risk Management Framework assume an organization can produce evidence of what an agent did and why. Most enterprises cannot do that today for any of their agents, let alone all of them.
There is also a trust problem underneath the technical one. Enterprises broadly understood what agents were capable of by 2024. 2025 was the year of pilots and proofs of concept. 2026 is the year production deployments are actually happening, and the uncomfortable pattern is that the more capable these models get, the wider the gap grows between what an agent can technically do and what an organization is actually confident letting it do without a human watching. AgentIQ was built to close that trust gap directly, not to make agents more capable. Making agents more capable is a model provider’s job. Making an enterprise confident enough to actually deploy those capabilities at scale is a governance problem, and that is the specific problem AgentIQ solves.
In-flow governance versus gateway governance: the architectural difference that actually matters
Most AI agent governance products today are built as a gateway. A gateway sits outside the agent, intercepting calls the agent makes outward, typically to a large language model or to a backend data source. That architecture is genuinely easier to build. A single gateway integration can, in principle, work across many different agents and frameworks without much custom engineering, because it never has to understand what is happening inside any individual agent’s reasoning process.
The tradeoff is that a gateway only sees the edges of what an agent does. It can approve or block a call going out to an LLM, or a call going out to a database, but it has no visibility into what happens between those calls, and critically, it has no way to intervene in the middle of an agent’s execution. If an agent is misbehaving right now, mid-task, a gateway-based tool generally cannot stop it. It can only refuse the next call that agent tries to make.
AgentIQ takes a different approach. Its SDK is embedded directly inside the agent’s own execution flow, integrated once when a developer builds the agent. Because the SDK lives inside that execution path rather than watching it from outside, AgentIQ can act in real time: it can hold an action for approval before it runs, block an agent that is making too many calls beyond a configured threshold, or shut a running agent down entirely if something is clearly wrong. That last capability, killing an agent mid-execution, is something gateway-based governance tools are architecturally unable to do, because they were never inside the execution path to begin with.
Because AgentIQ governs from inside the agent’s own execution flow, it needs a framework-specific SDK for every agent framework it supports, since different frameworks handle execution differently under the hood. A gateway can claim broader out-of-the-box compatibility for exactly this reason. The depth of control in-flow governance provides is worth the additional engineering required to support each framework properly, rather than trading control for universal compatibility.
How AgentIQ actually works
AgentIQ has two parts. One is a console, the interface where governance, risk, and platform teams configure policy, review agent activity, and approve or deny actions that get escalated to a human. The other is an SDK, a small library that agent developers integrate into their agent’s code, one time, per agent, regardless of how many tools that agent ends up using. Whenever developers add new tools to an already-integrated agent later, the SDK automatically reads those tools and populates them into the console without any additional integration work.
Functionally, AgentIQ’s model reduces to three moves, applied consistently to every agent regardless of what framework built it.
Govern. Every action an agent wants to take is evaluated against policy before it executes, not after. Policy can be scoped to a tool as a whole, or, more precisely, to the actual parameters inside a specific call.
Prove. Every prompt, every tool call, every data touch, and every outcome is logged in an immutable, replayable audit trail, the kind of evidence an actual auditor will accept rather than a log file nobody trusts.
The differentiator: delegation of authority for agents
A lot of AI agent governance today amounts to a binary switch: a given tool is either allowed or blocked, for every agent, all the time. That forces an impossible choice between autonomy and control. Block the tool and an organization loses the automation it wanted in the first place. Leave it open, and it accepts whatever risk comes with that, because the only other lever available is turning the whole capability off.
AgentIQ replaces that binary with something closer to how organizations already delegate authority to people. A junior employee can approve a small expense on their own, but needs sign-off past a certain threshold, not because the action is categorically different, but because the size of it changes who should be making the call. AgentIQ applies the same logic to an agent’s tool calls. It does not govern the tool. It governs the action.
Every tool call is evaluated against its actual runtime arguments, in addition to the agent’s own access permissions, and resolved on the spot to one of four outcomes: allow, confirm, escalate, or deny. The same tool runs freely when a call is low impact and stops for the right level of human judgment when it is not. A concrete example from the product itself: a refund agent can process a 40 dollar return entirely on its own, while the exact same tool call for a 4,000 dollar refund automatically routes to a named approver instead of the person running the agent. Nobody had to choose between giving the agent real autonomy and keeping the organization’s risk in check. The same tool call just resolves differently depending on what it is actually asking to do.
That is a meaningfully different level of control than allow or block ever offered, and it is the specific mechanism that lets an organization extend real autonomy to an agent instead of quietly limiting it to avoid the risk of getting governance wrong. Full autonomy where it is safe. Targeted human oversight exactly where it matters, and nowhere else.
This shows up as a four-way permission model across the platform: allow, confirm, escalate, or deny, with confirm routing to the person operating the agent and escalate routing to a different, more senior approver entirely. Denials do not need to enter a human queue at all. If an action is against policy outright, it is refused immediately.
What AgentIQ actually governs against
Beyond parameter-level policy, AgentIQ ships a specific set of governance capabilities aimed at the failure modes that actually show up in production agent deployments, not a generic feature list.
PII masking before the model sees it. AgentIQ detects personally identifiable information and masks it before it is sent to the LLM at all, not just before a response reaches an end user. That distinction matters because it protects against sensitive data leaving the organization’s boundary in the first place, including exposure to third-party model providers, rather than only cleaning up what a user is shown afterward.
Prompt injection detection. AgentIQ uses an open-weight model, an established model in the space, to score incoming prompts for injection attempts with a confidence level rather than a binary keyword match. Ambiguous cases can be routed for human review instead of only catching the obvious ones. Support for LangGraph, OpenAI agent, CrewAI, and others is on the roadmap.
Semantic topic and competitor blocking. Policy can block entire categories of conversation, politics or unrelated technical support, for instance, based on semantic classification rather than a keyword list, and the same mechanism can block semantic mentions of a named competitor rather than requiring an exact string match.
Code injection blocking. Pattern-based validation prevents an agent from passing executable code through to a tool that would run it, closing off a class of attack where a tool’s own execution permissions get abused through the agent as an intermediary.
Fail-safes for runaway agents. Token usage caps and maximum LLM iteration limits function as a stop-loss. Because an agent decides for itself when it has finished a task, with no human in that decision by default, a stuck agent can loop indefinitely and run up real cost before anyone notices. These limits cut that off automatically.
Model allow listing. Organizations can restrict which LLM providers and models an agent, or an entire team, is permitted to use, which matters for large organizations where individual teams might otherwise adopt models outside of an approved list without anyone finding out until a bill arrives.
Governance posture reporting. A CIO- or CISO-level view surfaces enforcement rate, human oversight rate, and total spend across the entire agent estate, in one place, instead of the fragmented, team-by-team visibility most organizations have today.
Framework agnostic by architecture, not just by claim
AgentIQ is not an agent framework, and it does not ask an organization to build agents inside a proprietary framework in order to be governed. Developers keep using whatever framework already fits their team, and AgentIQ governs whichever one that turns out to be.
Today that includes native support for LangGraph, one of the most widely used open-source agent frameworks. Support for OpenAI’s own Agents framework and for CrewAI is close to complete. Support for AWS Strands, Google’s Agent Development Kit, and Microsoft’s AutoGen is actively in progress, chosen specifically because each is tied to a major hyperscaler’s own agent tooling. The intent is a single console that governs an organization’s entire agent estate regardless of which framework built any individual agent, rather than a tool that only works well for whichever framework it was built around first.
Governance that does not cost anything extra to run
A reasonable objection to any governance layer is that it adds cost or slows things down. AgentIQ’s governance checks ride along with the LLM and tool calls an agent was already going to make. They do not introduce additional model calls of their own. AgentIQ measures cost and gives an organization a budget view into what its agents are actually spending, but it does not add to that spend by itself. The handful of specialized models AgentIQ does ship, the ones used for prompt injection detection and topic classification, are small, purpose-built, open-weight models used only for those specific governance tasks, not a general-purpose LLM an organization is required to adopt or pay for separately.
Why this is a governance problem before it is an AI problem
meshIQ has spent roughly 25 years building governance and observability for data in motion, the messaging and streaming traffic that connects enterprise systems together, running in some of the most risk-averse environments that exist, including institutions where 7 of the world’s top 10 banks currently run meshIQ in production. AgentIQ is not a separate company entering AI governance from a standing start. It applies the same govern and prove discipline to a new kind of traffic: the actions an AI agent takes, rather than the messages a system sends.
That history is a real, practical reason to take the approach seriously, but it is worth being precise about what it does and does not mean. AgentIQ does not require an existing meshIQ or middleware relationship to use. It was built as its own product, independent of meshIQ’s core platform, and it stands on its own for any organization whose problem is simply that it has AI agents running that it cannot see or control.
It is also worth stating plainly what governance is actually for here, because the term itself gets used loosely. Governance, in this context, is not a compliance checkbox exercise. It is the mechanism that stops an agent from going rogue, whether that means quietly exceeding the scope it was built for, or actively being manipulated into doing something it should never have been allowed to do. Any system with standing credentials and the ability to take financial or operational action, human or automated, represents the same underlying category of risk if nobody is watching it in real time. The 2016 Bangladesh Bank incident, in which attackers used stolen SWIFT credentials to attempt roughly a billion dollars in fraudulent transfers and reportedly succeeded in moving tens of millions before the attempt was caught, is a well-documented example of exactly that risk, unrelated to AI. An AI agent with access to payment systems and no in-flow governance is the same exposure, running at machine speed instead of human speed.
Who AgentIQ is built for
AgentIQ is aimed at the people responsible for an organization’s AI risk posture, not only the engineers building individual agents.
A CISO uses AgentIQ to close a visibility gap that otherwise cannot be closed by asking teams to self-report what they have built. A chief risk officer uses it to move governance in front of an incident, enforcing policy before an action executes rather than reviewing what already happened afterward. A head of AI or an AI center of excellence uses it to give engineering teams real freedom to pick whatever framework fits a given problem, while keeping one governance layer underneath all of it, so speed and control stop being presented as a tradeoff against each other.
Frequently asked questions about AgentIQ
Do I need to adopt meshIQ’s own agent framework to use AgentIQ? No. meshIQ does not build or sell an agentic framework. Organizations keep using whatever framework they have already chosen, LangGraph, OpenAI Agents, CrewAI, AWS Strands, Google ADK, Microsoft AutoGen, or another, and AgentIQ governs it.
What is the actual difference between AgentIQ and a gateway-based AI governance tool? A gateway sits outside the agent and can only see calls going out to an LLM or to backend data. It cannot see what happens in between those calls, and it cannot stop a running agent mid-execution. AgentIQ’s SDK sits inside the agent’s own execution flow, so it can intervene in real time, including shutting a misbehaving agent down entirely, which gateway-based tools cannot do.
What does delegation of authority mean for an AI agent? It means an agent’s permission to take an action is not fixed. It is evaluated at runtime, against the actual parameters of that specific action, the same way an organization already delegates spending authority to people based on the size of a decision rather than the category of it. AgentIQ resolves every tool call to allow, confirm, escalate, or deny based on those runtime arguments, so the same tool can run autonomously in a low-impact case and require a named approver in a high-impact one, without anyone having to block the tool outright to stay safe.
Does AgentIQ add cost or latency to my agents? No. Governance checks ride along with calls the agent was already making. AgentIQ does not introduce additional LLM calls of its own, so it does not add to token spend or response time.
How much engineering effort does the SDK integration require? The SDK is integrated once per agent, not once per tool. After that one-time integration, any new tool added to that agent is automatically reflected in the console without further SDK work.
Do I need an existing meshIQ or middleware relationship to use AgentIQ? No. AgentIQ is architecturally independent of meshIQ’s core middleware platform and stands on its own. If an organization has AI agents running that it cannot see or control, that is the exact problem AgentIQ solves.
Does AgentIQ require its own LLM? No. Organizations bring whichever model providers they already use. AgentIQ ships a small number of specialized, purpose-built models for specific governance tasks like prompt injection detection, not a general-purpose model.