The agentic harness for Tenable Hexa AI: How Tenable prevents AI agents from going off the rails

Learn why Tenable treats agentic LLMs as untrusted insiders, and how we’ve made sure you can control and monitor the AI agents making changes in your production security environment

Key takeaways

1. AI models can quickly understand data, but not your business. While modern AI models are great at reasoning, they don’t automatically understand your unique environment or who is allowed to do what. The “harness” is the custom-built layer that translates AI intelligence into safe, controlled actions specific to your organization.
2. AI requires a supervisor. Tenable treats our AI agents like untrusted insiders. Instead of relying on the AI to police itself, the harness strictly limits what the AI can see and do, and ensures a human reviews and approves any changes before they happen in your environment.
3. Trust requires proof. The harness ensures that every action AI proposes or takes is fully recorded, giving you an audit trail to confidently hand off real work to AI without losing control.

Every security vendor has an AI agent. The demos are good. They are supposed to be good, because a demo runs against data that nobody minds breaking.

The questions worth asking a vendor about their AI agents are the ones that come after the demo: 

• What happens when the agent is wrong? 
• What happens when someone feeds the agent a prompt designed to manipulate it? 
• If the agent changes something in our environment, what evidence exists afterward about what it did and who authorized its action?

When developing Tenable Hexa AI, the agentic AI engine of the Tenable One Exposure Management Platform, we tackled a difficult and critical problem that often gets overlooked: building the underlying infrastructure, the governance layer that safely turns the AI's decisions into actual changes without putting your production data at risk.

We call this layer the harness: the runtime control environment in which the model operates. The harness decides: 

• What context the model can see
• Which tools it can call
• What has to be validated before an action executes
• When a human has to approve an action
• What gets recorded afterward

The model reasons. The harness holds the boundary.

The model is the part you can subscribe to. The harness is the part that has to be built, and it represents most of the work of building an agentic AI capability. 

This blog presents what we learned building an agentic harness for Tenable Hexa AI.

Agentic AI: What goes wrong without a harness

Abstract warnings about AI risk are easy to write and easy to ignore. Here is what actually went wrong during our own development phase. The failures were more mundane, and more instructive, than the ones people theorize about.

1. The AI agent acted past its authority. Asking an agent to “clean up my criticals” is too ambiguous. Critical severity findings and critically rated assets are different objects, and “clean up” could mean remediate, accept the risk, or delete outright. A capable model will pick one and plan bulk changes across assets the requester cannot see, let alone modify. The model has no concept of who is asking. It does not know your entitlement model, and it will not infer one.
2. The model was confidently wrong about the customer’s own environment. The model told users that tags did not exist when, in fact, they did. It missed asset searches by IP address. It used the wrong tag format, using underscore where the platform expects a colon, and then it reported the failure as an absence of data. A model that has read the entire internet still has not read your tenant, and it will fill that knowledge gap with plausible invention unless you stop it.
3. It fell over on the boring queries. Relative time ranges crashed sessions. A query spanning more than 5,000 assets exhausted the context window and failed outright rather than degrading. An unbounded filter like “all assets where source contains servicenow” would run until something gave out.
4. It failed abstraction. Decomposed requests worked. A request like “give me a weekly security posture summary” failed because the model would not reliably break a broad objective into the sequence of scoped queries that answers it. The response was an ambiguous refusal, which is worse than a wrong answer because the user cannot tell whether the product is incapable or they phrased the request poorly.
5. The model refused work it was capable of. Before routing and scope logic existed, the model declined tasks it could clearly perform. Over-refusal is a real failure mode, and it is easy to cause while trying to fix the others.
6. Over-tuning the fix created a new failure. This was the least obvious lesson, and it came from our own work rather than the model’s. Early safety filtering was calibrated conservatively, and conservative filtering produces false positives. A false positive could also carry forward into the rest of a session rather than staying scoped to the request that caused it. Governance tuned too tightly fails as surely as governance that is absent, and it fails in the more confusing direction because a user experiences an over-cautious limit as a malfunction rather than as a control. Calibration is continuous work, not a setting you choose once.

There is a category above all of these, and it is specific to security. Much of the data in a security platform — such as hostnames, certificate fields, service banners, and finding descriptions — is written, in part, by people you do not trust. 

An attacker who can compromise a hostname can put a sentence in it, and a model reading that field as context can read the sentence as an instruction. Text arriving from your own environment is not a neutral input. In our world, security data is an attack surface, and it is one that does not exist in most other places agents get deployed.

The design stance behind the agentic harness: no standing trust

We settled on a set of core design principles that security teams already run for humans and service accounts: Assume no standing trust. Grant least privilege. Verify every consequential action. Record everything.

Applied to an autonomous AI agent, that means the controls sit outside the model, not inside it. A model instructed to behave is not a control, because instructions are input and input can be overridden or manipulated. So the harness holds the boundary. It decides what context the agent receives, which tools it may call, whether a proposed action is valid, when a human signs off, and what gets recorded when the action executes.

The useful property of the “no standing trust” design stance is that it does not depend on model quality, which means it survives model upgrades. Whatever ships next year will still be an actor whose intent cannot be verified at the moment it acts.

One request, end-to-end through the harness

The clearest way to explain a harness is to follow a single request through it. Let’s take the example of an actively exploited Chrome vulnerability, a fleet of Macs still running the vulnerable Chrome version, and a security professional who types “patch it” into an agentic LLM’s prompt.

Grounding before anything else. The agent is instructed not to state a platform fact from memory. Every assertion about your environment has to come from a tool response, and if the tool did not return it, the agent does not claim it. On its own, an instruction is a weak control for the reason described above, so it is paired with tool-grounded response construction rather than relied on by itself. Together, they remove most of the confident-invention problem.

Routing and decomposition. Not every step needs the same model. Cheap classification and lookup can go to a fast model, while multi-step planning can go to a reasoning model, and the objective is decomposed into scoped sub-agents that each own a narrow job: 

• Enumerate affected assets.
• Resolve them to managed devices.
• Map the CVE to the version that fixes it.
• Find the patch definition that delivers that version.

Decomposition is what makes the abstract request work, and it is orchestration logic, not model behavior.

Recursion and step budgets. Sub-agents that spawn work need boundaries. Otherwise, a reasoning loop will consume time and money until something external stops it. We cap maximum tokens, enforce layered recursion limits, and run a step budget that degrades to a partial answer rather than failing. Returning less is a better outcome than returning nothing after a long wait.

Authorization at the tool boundary, not the prompt. Every tool call passes through permission middleware that denies unauthorized access before execution. The AI agent acts with the entitlements of the person who invoked it and does not escalate beyond them, which means the answer to “what can the agent do?” is exactly “what can this user do?” 

Scale then changes the treatment. A single-asset change and an operation spanning thousands of assets do not create the same risk, so the wider the blast radius, the higher the bar: Larger operations require their full scope to be enumerated and explicitly approved. Some are unavailable unless an administrator has enabled them for that tenant, so the capability has to be granted rather than simply not blocked.

Guardrails on both directions of every call. Content checks run twice on every call, once before the model sees its input and once after it produces output. Screening only the user's prompt on the way in would miss most of what matters, because the risky content usually arrives from the environment rather than from the person typing. 

There is a case that sounds absurd until you hit it: A legitimate summary of a finding can itself contain the language that trips the injection filter, so the agent has to rephrase its own output to avoid being blocked by its own controls. Uploads are validated, and macro-enabled spreadsheets are rejected.

The approval gate. Before any state change, the agent stops and produces a written proposal with the number and IDs of impacted devices, the specific change policy, the deployment window, and the potential blast radius, as well as a statement that the action will not roll itself back. The user can narrow or widen the scope of changes, or decline all changes altogether. A refusal to apply all changes is sticky rather than something the agent relitigates on the next turn. Only after approval does it create a group containing exactly the approved devices; trigger the policy; and schedule the confirming rescan.

The approval gate is the capability Tenable customers have praised the most. Early access customers told us they were hesitant to try Tenable Hexa AI because they did not want to put their production data at risk. The approval gate is the feature that gave customers confidence they could trust the product.

Provenance and audit throughout. Every call emits token and decision events to our streaming and monitoring pipeline. Every run is traced. Everything correlates by request identifier. Conversation history is durable, and actions taken by the agent are stamped with their source so they are distinguishable from human actions in the record. For example, if six weeks later someone asks who approved a change and why, that question has an answer.

The part of the agentic harness nobody sees: knowing it still works

Here is the problem that consumes more engineering attention than any single control: models change constantly. Every prompt revision, tool change, or model swap can quietly regress quality or safety, and you cannot detect that by using the product. It feels fine right up until a customer finds the edge case you broke.

To address the challenge that evolving AI models create, Tenable runs two independent evaluation suites — one functional and one for safety — against every change. More than a hundred curated cases in Tenable Hexa AI score across roughly a dozen evaluators – single, automated checks – using distinct measurement methods, from deterministic rule checks to model-as-judge scoring to pairwise comparison.

Every case is a multi-turn conversation driven by a simulated user against the real agent in an isolated, reproducible environment, so results are comparable across runs, and drift shows up as a measurable drop against a pinned baseline rather than as an anecdote. One rule is absolute: Any run that makes an unexpected destructive call fails, regardless of how well it scored elsewhere. Results run in continuous integration, get triaged automatically, and get posted to the team channel.

Two things make the suite stronger over time. Real conversations that users rate poorly get promoted into the suite as new cases, so coverage hardens with each release. And because the suite is model-independent, we can evaluate a new frontier AI model against a fixed bar and adopt it on evidence rather than faith.

What an agentic harness unlocks

A harness may sound like a tax on capability. In practice, it is the thing that makes delegation possible at all.

Without a harness, an autonomous AI agent is a read-only tool. You can ask it questions and verify its work, which is useful and roughly the value of a good dashboard. The moment you want it to change something, the conversation becomes entirely about risk, and most organizations correctly stop there.

With an agentic harness, three things become available:

1. You can hand over consequential work, not just triage and summary but scoping, execution, and verification, because there is a defined point where a human approves actions and a boundary is enforced outside the model rather than requested of it.
2. You get evidence instead of assurances:  a record of what was proposed, what was approved, by whom, and what resulted is something you can give an auditor, a regulator, or a board. Trust in an agentic system is a documentation problem as much as an engineering one.
3. You can widen autonomy at your own pace. Scope is set per task rather than globally, so there is no all-or-nothing decision about the whole platform. You can start with something reversible, watch it run, then expand when you are ready.

Here’s an additional benefit of an agentic harness that is easy to miss: Because the harness holds the boundary outside the model, and the evaluation suite is independent of it, better models become an upgrade rather than a renegotiation. Tenable Hexa AI can adopt them without asking customers to re-extend trust from scratch.

Back to the post-demo question 

If you are evaluating agentic capabilities from any vendor, including Tenable, ask the following questions: 

• What stops an action the requester was not entitled to take? 
• What happens to instructions hidden in attacker-influenced data? 
• What does the agent do when a query is too large or the objective too vague? 
• What evidence exists after agents perform an action?
• How do you know quality did not regress the last time security vendors changed models? For example, does the agent still refuse what it should, ground its answers in real data, and stop for approval before making any changes? (Hint: If the answer is not a score against a pinned baseline, it is a hope.)

Access to a frontier AI model is not what makes agentic security work. Everything around the model does. That is the harness, and it is the difference between an agent you can watch and an agent you can hand work to. Everything above is what we built to make Tenable Hexa AI the second kind.

Learn more

• 30 days with Claude Mythos Preview: How Tenable adapted our security program, and why yours is next
• Tenable Hexa AI
• Meet Tenable Hexa AI: Agentic AI for exposure management
• Implement agentic AI in cybersecurity with Tenable Hexa AI: Reduce cyber risk at machine speed