AI agent discovery needs both network and identity context

At a glance

What this is: This is a joint integration for AI agent discovery that correlates Fortinet network telemetry with Astrix identity context to show what agents are, what credentials they use, and what they can access.

Why it matters: It matters because IAM and security teams cannot govern shadow AI, MCP servers, and privileged agent activity if they only see either the network trace or the identity trace, not both.

Context

AI agent discovery fails when network telemetry and identity data live in separate tools. Network logs can show that something connected, but they do not tell you whether the actor was a local agent, which credentials it used, or who is accountable for it.

The governance problem is broader than simple monitoring. If an agent is not tied to a non-human identity, access scope, and owner, teams cannot judge whether the activity is authorised, overprivileged, or a shadow deployment that escaped policy.

This integration is framed around continuous visibility across the enterprise, with the network layer providing reachability signals and the identity layer supplying ownership and privilege context. That combination is the difference between seeing traffic and governing the actor behind it.

Key questions

Q: What breaks when AI agent observability relies only on in-process telemetry?

A: You lose evidence quality as soon as the workload can influence the collector. In-process SDKs, framework callbacks, and self-reported logs are fine for debugging, but they are weak under compromise because the same agent that causes the event can suppress or falsify the record. Security teams should treat them as context, not proof.

Q: Why does an AI agent with no accountable owner create governance risk?

A: An AI agent without a clear owner can continue running after the original project ends, the creator changes roles, or permissions drift out of date. That creates an active identity nobody is reviewing. Governance risk rises because no one is accountable for purpose, access, or changes. Teams should assign an owner, document the agent’s purpose, and review access continuously.

Q: How can teams detect shadow AI before it becomes a breach issue?

A: Teams should correlate identity, endpoint, CASB, and procurement data to surface AI tools and services that bypass approved review. Shadow AI usually appears through existing enterprise access paths, so discovery works best when governance signals are treated as part of the detection stack, not a separate inventory exercise.

Q: What should IAM teams evaluate before allowing shared AI agent access?

A: They should evaluate whether the access path can be scoped per user, revoked centrally, and audited in a structured way. If any of those are missing, the organisation will struggle to prove what the agent did, who it acted for, and whether the access remained appropriate.

How it works in practice

Why network telemetry alone cannot govern AI agents

Network security tools are good at seeing connections, destinations, and protocol behaviour. They are not designed to answer identity questions such as which non-human identity initiated the session, what credentials authenticated it, or whether the activity belongs to an approved agent. In AI environments, that distinction matters because the same traffic pattern can come from a sanctioned automation, a shadow agent, or a developer test artifact. Without identity context, the control plane stops at observation and never reaches governance. Practical implication: use network visibility as a discovery signal, not as the full basis for agent approval or access review.

Practical implication: Treat network logs as a discovery layer, not as sufficient evidence of authorised AI agent activity.

How identity context turns agent traffic into governable inventory

Identity context adds the missing chain of accountability. Once traffic is mapped to a service account, OAuth app, API key, or personal access token, teams can see what the agent can reach, who owns it, and whether its permissions align with policy. That turns raw telemetry into inventory that can be reviewed, risk-scored, and audited. The key architectural shift is correlation: the system is no longer asking only what connected, but which identity made the connection and what that identity is allowed to do. Practical implication: maintain a live mapping between agent activity, credentials, ownership, and access scope.

Practical implication: Correlate every discovered agent to its NHI, owner, and permissions before allowing it into governance workflows.

Why shadow AI discovery depends on dual-plane visibility

Shadow AI is often invisible to agent registries because the agent was never formally onboarded. It still leaves traces in perimeter traffic and enterprise authentication systems, which is why discovery has to combine both planes. A discovery workflow that relies only on registered assets will miss unmanaged agents. A workflow that relies only on credential inventory will miss activity from tools that were never approved in the first place. The operational value comes from joining the two sources into one continuous view of activity, identity, and risk. Practical implication: design discovery processes that reconcile network events against identity records in near real time.

Practical implication: Build discovery around reconciliation between network events and identity records, not around a single source of truth.

NHI Mgmt Group analysis

Network-only discovery creates an identity blind spot: Perimeter telemetry can show that an AI agent connected, but it cannot tell you which non-human identity executed the action, who owns it, or whether the permissions are acceptable. That is a governance failure, not a logging failure. Security teams should treat network data as incomplete until it is joined to identity context.

Identity-only monitoring misses shadow agents by design: If an agent was never registered, lifecycle processes built around sanctioned inventories will not see it. That means traditional NHI governance breaks at the discovery stage, before review, recertification, or offboarding even begin. Practitioner implication: assume some agent activity exists outside your current inventory model and design for reconciliation, not registration alone.

Continuous visibility is now the minimum viable control for AI agents: Agents can create, modify, and delete across enterprise systems through credentials that look ordinary in isolation. The old assumption that a tool can be governed after it is discovered no longer holds when the discovery gap itself is the risk window. Teams need to shrink that window to near real time or accept unmanaged execution as a standing condition.

Identity blast radius becomes the right metric for agent governance: The practical question is not only whether an agent exists, but how far a given identity can reach if that agent is compromised, misused, or simply overtrusted. That reframes AI agent security around reach, ownership, and privilege scope rather than around tool popularity or deployment volume. Practitioners should govern the blast radius of each agent identity as a first-class control objective.

Auditable inventory now needs activity history, not static registration: AI agents move too quickly for a one-time asset list to remain useful. The meaningful record is a living inventory that ties activity, credentials, ownership, and policy findings together over time. Teams that cannot reconstruct that history will struggle with both audit evidence and containment decisions.

From our research library:

• Only 5.7% of organisations have full visibility into their service accounts, according to the Ultimate Guide to NHIs.
• Read next: AI Agent Identity Security Buyer's Guide

What this signals

Network-to-identity correlation is becoming the practical control boundary: Teams cannot govern AI agents from one telemetry stream alone. The operational model has to join perimeter logs, authentication records, and owner data so discovery produces an actionable identity record instead of a raw connection list.

Identity blast radius will matter more than agent count: As AI agents spread across SaaS, DevOps, and cloud systems, the question becomes how far each non-human identity can reach if it is misused. That makes access scope, revocation path, and ownership more important than simple inventory size.

Continuous discovery needs to become a programme, not a point tool: A one-time scan will miss agents that appear later, reauthenticate under new credentials, or move across environments. Security teams should plan for persistent reconciliation between network telemetry and identity state, because that is where shadow AI becomes governable.

For practitioners

• Map network telemetry to identity records Correlate firewall and proxy logs with NHI inventory so every detected agent connection resolves to an owner, credential, and permission set.
• Inventory shadow AI and unmanaged MCP servers Run continuous discovery across endpoints, SaaS, and DevOps tooling to find agents and MCP servers that never passed through formal onboarding.
• Attach blast-radius scoring to each agent identity Score write access, production reach, and cross-system permissions so risky agents are prioritised before broad access becomes normalised.
• Make ownership and offboarding auditable Require every discovered agent to carry a named owner, last-seen activity, and a revocation path so dormant identities can be retired cleanly.

Key takeaways

• AI agents are difficult to govern when network telemetry and identity context are split across different tools.
• The article’s central issue is not visibility in general but accountable visibility that ties traffic to credentials, permissions, and ownership.
• Security teams should build continuous reconciliation between network data and NHI inventory before shadow AI becomes an operational problem.

Key terms

• Shadow AI: AI agents, copilots, or connected tools operating without full visibility or governance from security teams. Shadow AI becomes an identity problem when those systems authenticate with unmanaged tokens, service accounts, or OAuth apps that can reach production resources.
• Identity context: The entitlement, ownership, and purpose information that explains why an action occurred and whether it was expected. For security operations, identity context turns raw alerts into decisions by showing which human or non-human identity acted and what it was allowed to do.
• Network-to-Identity Correlation: Network-to-identity correlation is the practice of binding traffic telemetry to the credential or non-human identity behind it. This turns raw connection data into governance evidence, allowing teams to evaluate ownership, privilege, and policy violations in the same workflow.
• Identity Blast Radius: The amount of damage a compromised identity can cause across systems, data, and infrastructure. In NHI environments, it is shaped by permissions, network reach, and administrative capability rather than by the credential alone. Reducing blast radius is a containment strategy that limits lateral movement and data exposure.

Deepen your knowledge

NHI governance, agentic AI identity, and machine identity lifecycle are core topics in our NHI Foundation Level course, the industry's only accredited NHI security programme. If you are building or maturing an IAM programme, it is worth exploring.