We built an AI harness for security: Then asked it to do less (but better)

AI security agents are built to understand the environment and asset context at runtime. They call multiple MCPs, gather from disparate sources on the fly, then make high-stakes decisions based on whatever context comes together, without validating if the context is correct. We think this is the wrong architecture for security work.

Instead of the AI assembling context on the fly, particularly in high stakes situations like cybersecurity, AI agents should be handed a deterministic source of truth for context. Before any AI tool is called, the environment needs to be fully discovered, relationships amongst assets like machines, software, and identities need to be mapped, and security findings need to be incorporated. This is how you reduce inference errors (i.e. hallucinations) and also get faster answers without wasting tokens.

When asset context is built at inference time (under token pressure, with no guarantee of reproducibility) three problems compound:

1. Cost grows proportionally to the number of MCPs and assets used

2. Non-deterministic execution introduces risks (like hallucinations) to decisions

3. The assembly process and resulting actions are hard to audit after the fact

For security, where the decisions include auto-patching production systems and pushing agent installs to devices that may bring mission critical systems down, that isn't a tradeoff worth accepting.

Like humans, AI agents also suffer from silos

Every tool in a security stack was built to see the environment from its own point. The endpoint platform sees only a subset of devices. The CMDB records another. The scanner reports against a third. IAM sees a subset of identities, cloud platforms see a subset of instances, SaaS tools see a subset of services. Each seems accurate from where it stands, but none was built to reconcile the sum of all systems.

Like humans, AI agents also suffer from the same silos. When an AI agent builds asset context from multiple separate MCP calls (endpoint management, endpoint security, vuln. scanner, IAM, CMDB, cloud), it does the same work a security analyst has done manually for years: stitching together a picture that should already exist. The analyst at least catches the obvious gaps. The agent acts on whatever it gets.

When that incomplete context drives a high-stakes action (quarantining a device, patching a system, deactivating a user), the impact is likely undesirable: a mission-critical system that goes offline, an execution that skipped official business approvals and SLAs, or an employee who's not able to work.

Security vendors are delegating context to AI (and that's bad)

As B2B security vendors adopt more AI, we see them all taking a similar approach: select a model, point it to as much data as possible (including MCPs), ask it to assemble context on demand, and then take "confident" action ("make no mistakes"). By overloading AI with stitching the asset context across multiple MCPs, solutions punish performance, increase inference costs (waste of tokens on multiple MCP/tool calls/fan out subagents), sprawl the identity attack surface (with more MCP credentials), and get non-deterministic results (each workflow can get different results dependent on how deep AI wants to investigate an asset).

Take as an example answering the question “What are my top security control gaps”. 

To answer this question, AI needs to: 

1. Use multiple MCPs & tool calls to gather your asset estate: all endpoints, data, identities, networks, code repos that need security controls.

2. Use multiple MCPs & tool calls to gather your security controls.

In our research (for an organization with 12 core systems on target), this question will typically take over 20 minutes, fan out 6-30 subagents, involve multiple rounds of iteration, and deliver different results per execution at high costs.

Alt: Conceptual diagram with question on the left “What are my top security control gaps?” and 2 sets of MCP and tool calls. 1st set, calling 6 sources of truth to find what assets need security control. 2nd set, 6 security systems to confirm if the assets are fully protected.

In short, our research showed AI agents suffer from the same problem as humans:

1. Confident action is dependent on durable context (the accurate representation of your asset and attack surface across all systems), and that's incredibly hard to come by.

2. Calling multiple MCPs is the agentic AI equivalent of a human solving security silos in CSVs, but faster and riskier when its goal is to run without a human in the loop.

We built Axonius AI and asked it: DO NOT build asset context

We built Axonius AI and deliberately asked it “DO NOT build asset context: We already built the correlation for you".

Instead, Axonius AI uses durable context built by the Axonius asset discovery before any AI call. Axonius AI doesn't stitch together a picture from multiple MCPs: it works from a pre-reconciled asset model that the Axonius Asset Cloud maintains continuously.

Here's how it works:

Alt: Conceptual diagram on how Axonius AI separates the context creation from the AI call at runtime, with steps matching the description below.

1. Axonius maintains an asset inventory of all systems that are interfacing with your data and processes.

2. The asset inventory is continuously updated through our asset discovery, which connects to systems to aggregate, correlate, and deduplicate information about assets and their state.

3. When Axonius AI gets to work, it leverages the asset inventory as its durable context, eliminating the need to build step 2 at runtime.

That was a deliberate architectural choice, reflecting four design principles we adhere to.

Four principles behind our architecture

We built the Axonius AI harness with the following principles in mind:

1. Deterministic first: Asset correlation and relationships are mapped before any AI call through Axonius's existing discovery pipeline. Because AI isn't guessing at asset context through multiple MCP calls, hallucination risk drops and inference cost drops with it. Context assembly is auditable from a single source.

2. Durable context: The asset context is assembled in one place, built the same way, where both humans and agentic AI can use it as a base for their work, without the burden of manually stitching silos via CSVs or MCPs. That work belongs to the platform (scalable, cost-effective, and predictable), not the inference layer.

3. Granular access and full auditability: Every AI action is bound by role-based access controls and data scopes. Every decision Axonius AI makes is traceable and repeatable. Security practitioners operate in compliance environments where incident response will ask what happened, why, and by whose authority.

4. Modular, use-case-proven: Before shipping, we built use cases with our harness internally for 15 days across security operations, IT, and cost optimization. The decision to create the durable asset context before any AI agent call gave us better results at scale, reaching over 500 pre-built agent use cases with high quality.

Durable context: serving multiple use cases from the same model

The case for durable context isn't only about reducing runtime error. It's about what becomes possible when a single reconciled asset model serves multiple consumers simultaneously.

Consider a device that hasn't been logged into for six months, owned by an employee whose account was deactivated. As part of the durable context, assembled before any AI call, this information unlocks multiple AI agents:

• Cost optimization: That's idle spend: a license, a device allocation, possibly cloud resources that should be reclaimed.

• Security: That's an unmanaged endpoint with a stale identity and an opportunity for attack surface reduction.

• IT process health: The existence of an unmanaged endpoint and stale identity for such a period uncovers an improvement needed in both IT decommissioning and Identity Governance deprovisioning.

With context assembled at runtime, each of the agents above would see only what it was asked to look for, at extra cost, with inconsistent results. A harness built on durable context serves multiple use cases with consistency.

The question worth asking every AI security vendor

The design tradeoffs in an AI security agent aren't always visible in a demo. But there are three structural questions worth asking to cut through the positioning:

• Where does context assembly happen? By the agent?

• How does it happen? Do I need to connect MCPs?

• Are there context risks (skipped MCP calls, different AI calls = different results [roll the dice], non-auditable logic)?

If the answer is "at inference time, by the agent," you have a system that reconstructs what's already known on every run. The extra token costs are real. The variability is real. The auditability problem is especially real the first time an automated action causes an outage and someone needs to reconstruct what the agent saw.

If the answer is "before the AI call, in a durable context, the architecture is built for the needs of security teams. That's the distinction worth carrying into your next AI security evaluation. Not whether the agent can reason, but what it's reasoning from.

See Axonius AI in action

If you would like to learn more about Axonius AI, how we built our harness, and how that can help your security program, book a demo and consultation with one of our specialists.