Over the past two years, AI use in the enterprise has matured. Whereas in 2022 and 2023, organizations raced to adopt chat-based assistants, today the focus is on agents. Agents, in our usage, are AI systems which work to achieve a goal by planning, using tools, and operating autonomously. Agents’ autonomy is their defining characteristic. That they act and operate in the world without granular human review requires a rethinking of approaches to steering, control, and oversight relative to past AI systems.
The instruments developed to govern earlier AI systems do not transfer cleanly to this setting. Model cards, fairness audits, and capability and bias evaluations are geared towards characterizing systems whose output is the object of concern. They describe what a model is likely to produce and the conditions under which it may fail. In contrast, the agentic paradigm moves the object of concern from output to action, and the relevant questions become operational. Which actions did the agent take, and which did it decline? What authorized those actions? What data and systems did the agent and its actions touch and are the effects reversible? Point-in-time governance artifacts are ill-positioned to answer these questions, because they were not built to observe or constrain an autonomous actor as it operates.
These are not prospective concerns. As agentic systems have been deployed across software development, customer operations, and internal automation, documented failures have followed. Anecdotes have emerged of agents taking destructive actions even when acting in good faith, like deleting customer data without appreciation for the consequences, authoring vast quantities of “slop” marketing content, and building unmanageable codebases through the progressive accumulation of ill-conceived architectural decisions. What these cases share is that the harm is realized through a new pattern of lighter human review, with agents acting at speed and scale in ways that human operators are not equipped to anticipate. As agent adoption becomes ubiquitous, these costs of autonomy will multiply absent a coherent approach to governance.
If governance is to be effective for agentic AI systems, it must be injected at a point where it can observe and constrain problematic behaviors as they occur.
We argue that the agent harness satisfies this need. The agent harness is the software layer that mediates between the model and the broader world. Every input reaches the model through the harness, and every action the agent attempts passes through the harness before it takes effect. The harness is therefore the surface at which we can make policy operative.
We use the term Agent Governance Configuration (AGC) for the practice of governing an agent by configuring this layer, and for the framework for doing so. In the market's emerging vocabulary, AGC is the discipline of producing governance-as-code, which are “versioned, human- and machine-readable files that define an agent's boundaries, permissions, escalation paths, and logging requirements, enforced through the harness at runtime”(Gartner, Scaling AI Agents Safely: Using the Agent Harness to Control High-Risk Use Cases, Lowendahl, Kumar, Govekar, 7 July 2026).
We argue in favor of harness-oriented governance as follows. First, we establish why the harness, and not a narrower interception point such as a model API gateway or an MCP gateway, is the appropriate surface for governance (Section 2). We then enumerate five agent controls the harness exposes and consider the most consequential practical question, which is how to set those levers for a given use case and a given risk tolerance (Section 3). We argue that the builders of agent harnesses should converge on a common set of configuration levers, so that organizations can express their policies once and enforce them across the several agents they operate (Section 4). Finally, we describe what remains once the levers and their settings are understood, namely the translation of an organization's policy into a working configuration, which is the problem that motivates Agent Governor, now available in research preview.
Why the Harness Is the Right Surface for Governance
An AI agent harness is the software that connects an LLM to the enterprise environment and the broader world. It defines the AI agent's context, tools, permissions, memory, verification steps, escalation paths, and auditability. As organizations grant AI agents more access, the harness is the leverage point for enterprises to translate governance intent into operational limits. Through a combination of deterministic operational controls and the probabilistic reasoning of foundation models, a well-configured harness enables AI agents to operate safely, consistently, and in accordance with enterprise policy.
The harness mediates between the model and the world. Figure 1 sketches a typical instantiation. Harnesses play an outsized role in enabling agents’ autonomy by managing context and session state, facilitating tool calls and feeding tool responses back to the LLM, and aiding the LLM with orchestration of increasingly sophisticated workflows like owning the mechanical steps involved in delegating to a subagent. For the purposes of governance, we focus on four core harness operations:
- Processing inputs before they reach the model,
- Passing control from the model to an invoked tool and back,
- Logging session events, and
- Enforcing constraints on what the agent may do.
We confine our attention to these four, because they are the functions through which governance is exercised.
Governance could, in principle, be applied at a narrower point, and two such points are common in practice. API gateways sit between the agent harness and the language model. API gateways enable admins to inspect and control the prompts sent to the model and the completions returned. Likewise, MCP gateways sit between the agent harness and the external tools the agent calls over the Model Context Protocol. Analogous to API gateways enabling inspection of model inputs and outputs, MCP gateways enable inspection and control of those tool calls. Both types of gateways are useful for governance, but both share a limitation in that each observes only the traffic that flows through it.
For instance, an API gateway sees the model's inputs and outputs, but is not well-positioned to tease apart and govern inter-agent interactions. Likewise, MCP gateways don’t give governors a window into an agent’s local operations or any other behaviors outside of the MCP protocol. Only the harness touches the full range of the agent's behavior, from the input it receives to the actions it ultimately takes. That completeness qualifies the harness as the primary governance surface.
Beyond completeness of control, identifying where and how to inject governance is a simple exercise in understanding how harnesses operate. Agent harnesses are, at their core, finite state machines. They operate according to a well-defined set of rules for transitioning among a number of ‘states’, like starting a session, calling a tool, or returning control to a user at the end of an autonomous workflow. For the purposes of governance, it is most helpful to focus on the transition events where the agent’s harness moves from one state to another. Transition events are deterministically identifiable and thus serve as an avenue for programmatically checking – e.g. via a hook – that governance requirements are satisfied and conditionally taking action based on the agent’s current context and the states it is transitioning from and to. Because the set of events is finite and well defined, governance can be applied precisely, at the junctures where a given risk arises.
The event set characterized in Figure 1 is simplified for the sake of illustration. In practice, production harnesses define a rich taxonomy to account for the increasingly general operations today’s agents are meant to accomplish. OpenAI, for example, names 10 distinct transition event types as being operative in their Codex harness. Anthropic goes further, with 30 event types built into the finite state machine underlying Claude Code.
The industry is slowly adopting this approach to agent development as a standard of practice. The most popular off-the-shelf agent frameworks share the same basic shape with a harness that mediates the model, exposes a lifecycle of events, and admits hooks at those events. Anthropic's Claude Code and Claude Cowork are built this way, as are OpenAI's Codex and Cursor, and the pattern extends beyond them. Of course, as the prior paragraph notes, there is not yet a standard of which events should be defined and configurable in a harness.
Nevertheless, focusing governance at the harness layer does not require a bespoke or proprietary mechanism in the way that gateway-like tools do.
Harness configuration uses the configuration surface that agents have built-in, making it possible to affect governance natively and directly. It also has the benefit of being harness-agnostic by design, as configuring a new harness means mapping controls onto its native settings and state machine without the need for proprietary, “sidecar” infrastructure like an API gateway.
Agent Control: Governing through Harness Configuration
We now turn our discussion to the specifics of harness configuration. We refer to these configurable controls collectively as the levers of agent governance configuration, the knobs a governor sets to shape an agent's operational envelope, to steer its behavior. This section enumerates five key levers a harness should expose and then speaks to governance practice by considering how governors should approach setting them for a given use case and a given risk tolerance.
At a minimum, to enable effective governance, agent harnesses should make configurable the agent’s connected tools, the flow of data into and out of the model and its context, the injection of advisory content and guidelines, rules for human approval, and the observability of the agent.
- Tool access
An agent's tools are the means by which it acts on the world, so the set of tools available to it defines the outer boundary of what the agent can do at all. This lever governs which tools and MCP servers the agent may reach and on what conditions, through allow, block, and elicitation rules. It is the most direct control an organization has over an agent's capacity for both useful and harmful work. The harness should expose configuration of tools natively, by allowing administrators to connect and block tools directly via the harness without additional infrastructure.
Further, the harness should expose configuration for every tool the agent has access to rather than only those reached over the Model Context Protocol. MCP gateways address this lever from the outside and can typically reliably govern only the tools the agent accesses over the protocol (i.e. omitting local tools that enable reading and editing files on an employee’s laptop, or tools invoked via a command-line interface to access a remote resource).
- Data flow
An agent's decisions are only as sound as the information it acts on, and its data access is often the channel through which it can be misled or through which it can cause a leak. This lever inspects the content moving in and out of the model and its context, classifying tool results, intermediate outputs, and subagent interactions to prevent the exfiltration of sensitive data and to catch the hazardous cases where broad data access coincides with broad action authorization. API gateways address this lever, in part and from the outside looking in, since they can process and moderate prompts and completions. API gateways are not able, however, to fully inspect the source of a piece of data.
For instance, if an agent invokes a sub-agent to do work on its behalf and communications from the sub-agent feed back to the main agent, a gateway only looking at requests sent to a model provider will not understand, or be able to govern, the why behind the agent’s context.
- Advisory content and guidelines
Much of what an organization expects of an agent cannot be reduced to deterministic, objective rules. This lever concerns how those qualitative expectations are conveyed. Advisory content is any content that is injected to the agent context to steer its behavior, including system prompts, supplementary instructions, skills, and other pieces of guidance injected dynamically based on the situation. A configurable harness should support a wide range of options to inject such guidance. Dynamically-supplied guidance represents an effective fallback for influencing the agent's decision making in circumstances that can’t be fully anticipated with deterministic blocks.
4. Human approval
Some actions are too consequential, or too ambiguous, to delegate fully to the agent. This lever governs when the agent must stop and obtain a person's authorization before proceeding, keeping a human in the loop precisely where that judgment is most needed. Harnesses should make it feasible to force escalation as an intervention outcome, as simply blocking and allowing actions is overly coarse.
5. Observability
Recording the events of a session as telemetry is the feedback loop by which a configuration is judged and refined, and it must be in place from the outset. “You cannot manage that which you do not measure.” The harness is the only vantage point from which everything an agent does, can be observed. It records what happened and shows how the agent reached each outcome, creating the evidence required for compliance, security, and audits.Gateways record the traffic that passes through them, but only the harness sees the full course of a session, from the input received to the action taken.
Observability is therefore what makes the agent's behavior, and the effect of governing it, legible to the people accountable for it. Harnesses should adhere, at a minimum, to the OpenTelemetry standard for GenAI applications to be considered governable.
Setting the levers
Governance is applied through these levers in two ways. The simplest is through static settings exposed by the harness. For instance, in most harnesses, a tool can be disabled outright, or made to require human approval on every invocation. Such settings are unconditional and don't involve any custom runtime logic. The second way is through mechanisms that act conditionally, running governance logic at a transition event, reading the circumstances of the event and the agent's context, and deciding on that basis whether to intervene and how. Hooks are a common example of such a mechanism, among others a harness may expose, like skills and subagents.
Figure 2, illustrates configurations of this variety, extending the basic agentic harness from Figure 1 to show where hooks can be configured to check conditions for each state in the harness’s finite state machine.
However applied, an intervention can be geared towards enforcement or towards steering. Runtime enforcement moderates the agent’s behavior by stopping prohibited actions, pausing the agent for human approval, or allowing low-risk actions to proceed. In contrast, steering preserves the model’s control and instead shapes the model’s judgement, by supplying advisory content suited to the situation. This can be done deterministically by configuring hooks to trigger for particular transition events in the finite state machine and the outcome of the hook’s execution is to add guidance to the agent’s context. For example, a hook could be configured to trigger whenever the agent attempts to retrieve content from public websites and inject guidance on how to handle untrustworthy data without outright blocking the action. In this sense, the hook is part of the invocation mechanism, but the substance of the steering is the guidance itself.
Good governance requires arranging this configuration in advance, so that the risks a use case presents are prevented where they can be and mitigated where they cannot. How a governor sets it up depends on the organization’s tolerance for each potential risk and whether those risks can be identified deterministically and at what cost. Some behaviors can be specified precisely and detected cheaply, such as reading files types that typically contain configuration secrets; others cannot be easily specified a-priori, like assessing whether a particular work task is a valuable one for an agent to take on, given its expected performance relative to a human and the relative costs, including the cost of review. A risk that is both unacceptable and deterministically detectable should be prevented through enforcement that blocks the action or gates it behind human approval, while a risk that cannot be reduced to an explicit rule must be addressed through steering.
The distinction between enforcement and steering is analogous to the distinction between securing an agent and governing it.
Security relies on enforcement alone, while governance an agent requires behavioral steering in addition to ensuring the agent is secure, because much of what an organization cares about is behavioral.
The levers described here are available in harnesses built on the pattern laid out in Section 2, but the form of these levers is not yet consistent across harnesses and not all agent harnesses in the market implement these levers. We turn attention to that lack of standardization next.
Calling for a Standard for Configurable Harnesses
The five levers laid out in the previous section comprise what a harness ought to expose as configurable at minimum. Which levers a given harness actually implements, and in what form, varies widely in practice. Each harness ships its own configuration interface and its own vocabulary, so where one names and exposes a lever, another may name it differently or omit it. An organization that runs five or ten agents must then develop deep expertise in five or ten dialects of governance, and a policy worked out for one agent has to be reworked, by hand, for the next. Fragmentation of this kind raises the cost of governance, undermines consistency across agents, frustrates any attempt to audit an organization's posture as a whole, and does not scale. The objective we have described, that an organization states its governance requirements once and has them honored wherever its agents run, depends on closing this gap.
Among the harnesses built for coding, a measure of convergence has already happened on its own. Claude Code, Codex, and Cursor expose many of the same primitives, sharing a core set of lifecycle events and permitting mechanisms for both enforcement and guidance, via hooks and skills. While these don’t follow a formal “standard”, their shared shape represents a key step towards standardization that will make governance easier across harnesses. In turn, Microsoft's Agent Control Specification is a more deliberate attempt to write a standard down, though still an early draft. Its primitives overlap with these harnesses in its definition of finite state machine events, and shares concepts on the enforcement side, where a policy may allow, warn, deny, escalate, or transform an action, but it does not share naming – hooks are not a formalized concept, for instance – and provides no avenue for the guidance-oriented interventions.
While the coding-oriented harnesses have similar configurability, this does not hold industry-wide. Most agents on the market, and especially those embedded inside applications, expose none of these levers, or expose a small and unfamiliar subset of them, under different names and with far less reach. An organization cannot govern at the harness what a harness does not let it configure, and a policy written against one such surface carries over to the next only by being rebuilt. The convergence visible at the leading edge has not reached the long tail of agents that organizations are actively adopting and seeking to govern.
Unfortunately, adjacent governance tooling that relies on chokepoints in the agent’s operation is no remedy. API and MCP gateways carry no shared governance standard of their own, so an organization that turns to them must work out and maintain a separate configuration for each, in addition to whatever the organization configures at the harness layer. Because the harness must be governed in any case, and stands as the one surface with full visibility into the agent's behavior, it is the place to consolidate rather than one more surface to learn.
What we advocate, then, is deliberate convergence. We hold that the builders of agent harnesses should settle on a shared set of governance levers and a common vocabulary for them, so that a policy expressed once can govern an agent wherever it runs. That shared set has to cover both the deterministic levers and the advisory ones. A standard confined to enforcement, as in the Agent Control Specification, is insufficient. Governing agents well depends on both enforcement and steering.
Our own position warrants a brief comment. We argue for this convergence, and we care that it happens, but we do not put ourselves forward to author the standard, conscious of the trap in criticizing self-appointed authorities and then assuming the role. We also hold that settling what a harness should make configurable, necessary as it is, is the more tractable half of the task. The harder half, the one that decides whether an agent is governed well, is deciding what to set those levers to. Deciding which risks to block, which to escalate, which to steer, and how. That is the problem Credo AI works on.
From Policy to Configuration
Setting the levers means making a decision for each requirement in an organization's policy: whether it is met by blocking an action outright, by escalating it to a person, or by steering the agent with guidance. That choice depends on how much risk the organization will tolerate and how reliably the requirement can be checked. Taken together, these decisions are the translation of a policy into a configuration, the most difficult part of governing an agent.
This is the problem Agent Governor, launching in research preview, is built to solve. Agent Governor takes as input a policy articulating how agents at an organization should behave and outputs a configuration that puts the policy into effect. We derive the configuration by creating what we call ‘artifacts’ – particular settings of each harness lever – to satisfy each requirement defined in the input policy. The product generates configurations both for enforceable, objective requirements, and for behavioral requirements via steering-oriented configuration artifacts. At launch, we provide configurations for Claude Code, specifically. The artifacts we generate are hooks and skills, along with configuring Claude Code’s formal settings.
Today, this translation takes a curated form.Agent Governor ships a set of policies drawn from Credo AI's control library, the controls we believe every organization should put in place to manage the risks of agent use. Our out of the box policies cover three risk tolerance levels, constituting policies suited to orgs seeking a permissive, balanced, or strict agent risk posture. We are working to add the features necessary to support organizations in bringing, and even building, policies of their own which can be passed through our policy translation system to obtain a configuration that the organization can install in its agents to bring them under governance.
Finally, observability is the AGC lever that tells us whether the rest of the configuration is working. Agent Governor provides a telemetry backend that receives the emissions from an agent's harness and uses them to surface governance-relevant insights that point to whether the configuration is behaving as the policy intended and where it is falling short. The gaps this surfaces can inform refinements to the policy and configuration over time. A configuration is, in the end, a hypothesis about how the agent will behave, and gathering telemetry enables us to test and improve.
The failures we discussed at the beginning of this paper share a single feature. Each occurred at a point in the harness’s operation where a control, properly configured, could have provided the necessary safeguards to prevent the risk from materializing. For an agent, governance needs to include building runtime protections. Configuring the harness is the most effective way to introduce those protections. Agent Governor is the solution to creating the policy-actualizing configurations that enable enterprises to effectively govern their agents.
For more, read:
1. The Agentic Trust Moment blog— our CEO Navrina Singh on why getting agentic AI right depends on governance-as-code at runtime.
2. Introducing Credo AI Agent Governor blog – our Head of Product, Ehrik Aldana on using the Agent Harness to trust and control your agents and their actions.
DISCLAIMER. The information we provide here is for informational purposes only and is not intended in any way to represent legal advice or a legal opinion that you can rely on. It is your sole responsibility to consult an attorney to resolve any legal issues related to this information.
.png)