Is Your Security Agent Seeing the Whole Network?

By Lazar Milicevic · Published October 10, 2026 · 10 min read

You're about to let an AI agent triage alerts or push remediation on your devices. But the agent can only reason about what its data feeds show it, and the devices most likely to hurt you are the ones that never show up. Before you grant autonomy, you need to verify the inventory underneath it.

The core problem: an agent can't report its own absence

An endpoint security platform only reports on devices where its agent is installed. If a laptop never received the agent, or someone removed it, that device doesn't appear as "unprotected." It simply isn't in the data. Okoone's write-up states this structural point plainly, and it's the reason "check your console" is not a coverage audit.

Now put an autonomous agent on top of that console. It will triage, prioritize, and act on a world that looks complete from the inside. Every decision is internally consistent and quietly wrong about the edges.

The scale of the gap, at enterprise level, is not small. VentureBeat reports that across the Axonius customer base, 12.7% of devices in a median inventory of roughly 298,000 devices are missing their expected security agent. Axonius presents this as data from its own customer base, not as a result of the Ponemon survey (see its RSAC 2026 recap). Axonius's own material also confirms the ~298,000 median inventory, drawn from 900+ customers, and notes more than five tools reporting exposures per organization (Axonius Adapt 2026 recap).

Two caveats before you quote that number anywhere:

• The 12.7% figure comes from Axonius customer deployment data as reported by VentureBeat and Axonius. It is not a result from the Ponemon survey.
• It's an enterprise statistic. A median of ~298,000 devices says nothing about a 6-person company with 20 laptops and a handful of cloud accounts. Don't assume 12.7% applies to you. Do assume the mechanism does: any inventory built from the tools that watch devices will miss devices those tools don't watch.

The takeaway isn't "you have a 12.7% gap." It's "you don't know your gap until you measure it from a source that doesn't depend on the agent."

What the 2026 research says about data readiness

The 2026 Axonius Actionability Report, conducted with the Ponemon Institute, surveyed 662 IT and security professionals in the United States (Axonius). Axonius is a vendor selling inventory and exposure tooling, so read the findings as a vendor-sponsored survey. Still, the pattern is useful because it matches what builders see in practice:

Sources: VentureBeat for the 52% and 63% figures; Axonius press release for the rest.

Read the first two rows together. A majority is willing to let agents act, and a larger majority says the data feeding those agents is incomplete. That's the actual risk: willingness to automate is running ahead of data quality.

The biggest remediation challenges reported were unclear prioritization (26%), no clear ownership (24%), and inconsistent data across tools (21%). Notice that two of the three are data problems, and the third (ownership) is a data problem too: an asset record with no owner field can't be routed to anyone, human or agent.

On reconciliation cadence, the sources disagree. Axonius's Adapt recap says 87% of surveyed teams aren't reconciling their asset inventory daily, matching VentureBeat's 13%-reconcile-daily figure. A different Axonius blog post gives a different cadence number. I'd treat "most teams do not reconcile daily" as the safe statement and not lean on any single percentage.

The same failure mode, outside security

If you run a small business, you might be thinking this is a SOC problem. It isn't. The failure mode is general: an agent's confidence is independent of the completeness of its inputs.

Examples I see regularly in small-team automation:

• An invoicing agent that reconciles payments against one bank feed, while a second account (opened for a side project) isn't connected. Everything it reports balances. It's just not everything.
• A lead follow-up agent working from the CRM, while half of real conversations live in a shared inbox the CRM never ingested.
• An access-review agent that audits SaaS accounts listed in the identity provider, missing the tools someone signed up for with a personal email.

Same shape as the endpoint gap: the thing missing from the data is the thing the agent cannot flag as missing.

Gravitee's State of AI Agent Security 2026 report (900+ executives and practitioners) shows the agent-side version of this. It found that on average only 47.1% of an organization's AI agents are actively monitored or secured, and only 14.4% report all agents going live with full security and IT approval (Gravitee). Gravitee also reports that 88% of organizations had confirmed or suspected AI agent security incidents. Caveat: this survey was run by a vendor, so it may be biased. Use it as a directional signal, not a benchmark.

The practical reading: your inventory problem has two layers. Devices and accounts you don't know about, and agents you don't know about.

A readiness check you can run this week

Before an autonomous agent gets write access to anything, run these checks. None of them require buying a platform. They require a second source of truth that doesn't depend on the system you're auditing.

1. Build an independent inventory. Pull device or account lists from at least two sources that don't share a dependency. For a small team: your identity provider (Google Workspace, Microsoft 365, Okta), your MDM or device-management tool, your network's DHCP/router client list, and your billing/SaaS spend (card statements show tools nobody registered).

2. Diff the sources. Anything present in one source but absent from the security console is a candidate gap. Here's a minimal sketch:

import csv

def load_ids(path, col):
    with open(path, newline="") as f:
        return {row[col].strip().lower() for row in csv.DictReader(f) if row[col].strip()}

edr_devices   = load_ids("edr_export.csv", "hostname")
idp_devices   = load_ids("idp_devices.csv", "device_name")
router_leases = load_ids("dhcp_leases.csv", "hostname")

independent = idp_devices | router_leases
missing_from_edr = independent - edr_devices
orphaned_in_edr  = edr_devices - independent

print(f"Seen independently but no agent report: {len(missing_from_edr)}")
for h in sorted(missing_from_edr):
    print("  ", h)
print(f"In EDR but not seen elsewhere (stale or renamed?): {len(orphaned_in_edr)}")

Hostname matching is crude (names get reused, renamed, or spoofed), so treat the output as a worklist, not a verdict. Serial numbers and MAC addresses are better join keys when you have them.

3. Verify out-of-band. "The console says the agent is installed" is not verification. Check from a different path: a script that queries the endpoint directly, or an MDM compliance report that independently confirms the agent process or package.

4. Check freshness. For every record, ask when it was last confirmed. A device last seen 90 days ago is not "protected," it's "unknown." Add a last_verified timestamp to your inventory and have your agent treat stale records as untrusted.

5. Check ownership. For each asset, can you name a person or team? If not, an agent that finds a problem has nowhere to send it. Ownership gaps were the second most common remediation challenge in the Axonius survey (24%).

If you want a rough rubric for deciding when to grant autonomy, here's mine. It's my own heuristic, not an industry standard:

Some vendor coverage suggests a minimum verified coverage level before autonomous remediation. I couldn't trace a specific threshold to a data source or a standards body, so don't present any such number as an industry norm. VentureBeat's piece discusses checking that discovery, CMDB, and EDR data agree closely before trusting an agent; read it for the framing, and set your own threshold based on how bad a wrong action would be.

What fixing the gap actually looks like

The case data from enterprise deployments shows the fix is usually consolidation plus verification, not a smarter agent. These come via VentureBeat's reporting and Axonius material, so they are vendor-adjacent accounts:

• TransUnion went from 70% to 99% endpoint coverage after out-of-band verification.
• Western Union went from 85% to 99% by consolidating data from 38 tools.
• Lumen found 1.1 million assets where its CMDB showed 17,000.
• UKG used an automated CrowdStrike sensor upgrade to close 100,000+ coverage gaps to near zero, and cut reporting time from six hours to minutes (per Axonius).

Look at what these have in common: none of them are "we deployed a better model." They are "we found out what we actually had." Lumen's number is the starkest, a roughly 65x difference between what the configuration database claimed and what discovery found.

Axonius itself reports running 1,400-plus adapters, including an Anthropic adapter (GA June 15) that discovers shadow Claude Enterprise installations (VentureBeat). That's worth noticing independent of the vendor: the inventory now has to include the AI tools and agents themselves, since an unmonitored agent is just another unmanaged asset.

For a small team without 1,400 adapters, the equivalent is smaller but the same idea:

# inventory_sources.yaml — every source that can "see" an asset
sources:
  - name: identity_provider
    covers: [users, managed_devices, oauth_app_grants]
    refresh: daily
  - name: mdm
    covers: [laptops, phones, installed_agents]
    refresh: daily
  - name: network_leases
    covers: [anything_on_the_lan]
    refresh: hourly
  - name: billing_exports
    covers: [saas_subscriptions, cloud_accounts]
    refresh: monthly
reconcile:
  join_keys: [serial_number, mac_address, email]
  flag_if_missing_from: [mdm, edr]
  stale_after_days: 7

The point of the file isn't the syntax. It's forcing you to write down which sources exist and what each one is blind to.

Governance: the rules are still moving

If you sell into the EU or operate there, regulatory timing affects how fast you need this in place. The EU's Digital Omnibus on AI shifted the high-risk obligations: Annex III stand-alone high-risk obligations move to 2 December 2027, and Annex I product-embedded AI to 2 August 2028. Article 50 transparency obligations still apply from 2 August 2026. The Council gave final approval to the Omnibus on 29 June 2026, and systems already on the market get a grace period to 2 December 2026 for Article 50(2) machine-readable marking (Cloud Security Alliance research note).

I'm deliberately not quoting penalty amounts. I've only seen those in secondary sources, so check the AI Act text and your counsel before relying on any figure. This is not legal advice; confirm how these dates apply to your situation with a qualified professional.

A caution on the "frameworks require X" claims you may see in vendor content: if a piece says a named framework (including the Cloud Security Alliance's agentic work) mandates specific gates or a specific validation percentage, check the primary document yourself on the framework's official site before repeating it. I haven't verified such specifics, so treat them as unverified until you see the source.

Common ways this goes wrong

A few failure patterns worth naming, from building these systems:

• Treating the console as ground truth. The console is a view, not the territory. Every coverage number derived solely from the tool being measured is circular.
• Granting autonomy before ownership exists. An agent that can detect but not route is noise. An agent that can act without a named owner is a liability.
• Letting stale records count as healthy. If "last seen" isn't part of the decision, dead devices inflate your coverage figure.
• Spreadsheets as the system of record. 55% of the surveyed teams still track remediation in spreadsheets. Spreadsheets aren't evil, but they have no change history, no enforced schema, and no way for an agent to trust a cell.
• Skipping the agent inventory. If you can't list your own AI agents, their permissions, and their data sources, you can't claim to have a complete picture.

Where this fits in practice

The security version of this problem is a subset of a broader one: agents are only as good as the context they're fed. The unglamorous layer underneath is what matters most, pipelines that pull from every relevant source, normalize records into a consistent schema, track when each fact was last verified, and hand the agent structured context instead of a pile of exports. The diff-and-freshness checks above are a stripped-down version of that idea.

If you're about to give an agent write access to something that matters, the cheapest step is to pressure-test the data first: list your sources, find the blind spots, and decide what the agent should be allowed to do given what it can actually see.

Work with BizFlowAI

If you'd rather have this built for you, that's what we do: production AI automation for solo founders and small teams — agents, integrations, and document pipelines that actually ship.

Request a free discovery call — 30 minutes, we map the highest-ROI automation in your workflow. No pitch deck, just engineering.

More guides like this on the BizFlowAI blog.