What AI is running, and what can it reach?
Boards, auditors and regulators are asking it. Most programs can answer the first half from a procurement list and none of the second half.
of organizations could say all their AI agents went live with full security approval
Gravitee, 2026, survey of more than 900 security leaders
The first run is usually the first accurate count.
Who authorized this agent?
The credential it uses sits in a config file with no owner and no approval record. When it does something unexpected, there is no one to ask.
Why does offboarding not end access?
The IdP account is disabled the day they leave. The OAuth grants and API keys on their laptop keep working for months.
How far does it reach?
An agent authenticated to several systems can reach further than the person it acts for. Privilege nobody approved.
Every tool sees one hop. None sees the path.
The credential in the config file has no tool. That is where the path starts, and that is why the inventory never becomes an exposure.
AI lives in two places. Unizo covers both.
Unizo normally reasons over findings your tools already produce. AI is the exception, because no existing tool produces them. Here Unizo discovers as well as reasons, on both sides.
- Platforms
- AWS · Azure · GCP
- Asset
- managed AI service
- Identity
- role/ai-agent-prod
- Reach
- Customer data store
- Tools
- Claude Desktop · Claude Code · Cursor · VS Code · ChatGPT · Codex
- Asset
- mcp-postgres
- Credential
- api key in mcp config
- Reach
- role/ai-agent-prod
The right-hand readout reaches into the left. That is the cross-domain chain, and it is the one the rest of this page follows.
The AI your teams run, wherever it runs. Not the AI your employees are chatting with.
An agent is not a service account.
Some agents act for a person. Some run on their own. That difference decides who is accountable and how far the reach goes. Unizo models the delegation, cross-references it against HRIS, your identity provider and cloud IAM, and assigns every AI identity to a person or a team.
Three things, at once.
A credential in a config file is common. Most reach a dev database, a staging bucket, or nothing that matters. Those are hygiene findings and they belong in a report, not in a queue. An AI exposure qualifies when all three hold. Any one alone is noise. That test is why the queue stays short.
From found to verified closed.
Credential in an AI assistant config reaches a production database
- Anchor seed
- api key in mcp config
- Evidence attached
- 4 connected signals
- Suggested intervention
- Rotate the credential
- Accountable owner
- Platform Security
- jdoe-laptop api key in mcp config
- mcp-postgres
- role/ai-agent-prod Chosen breakpoint
- db-customers
- Qualified
- Investigated, planned
- Driving
- Verified closed
The config file names the target. The connection is read, not guessed.
Rotating the credential removes the cause. Restricting the role breaks the path and leaves the credential in place.
Closure is checked against the environment, not the ticket.
The same loop as everything else.
The Exposure Analyst investigates and drafts the Plan. Work routes to the accountable owner through the ITSM you already run. The owner applies the change. Closure is checked against your environment. Guardrails and prompt filtering are a different job, in the request path. This is posture: what AI exists, who can reach it, where it chains to sensitive data, and how the exposure gets closed.
- Qualify
- Investigate and plan
- Drive remediation
- Verify
What people ask about this.
What counts as an AI exposure?
A path from an AI asset, through an identity it holds, to a system that matters. Not the presence of an AI tool, and not a credential on its own.
Is this AI security posture management?
Posture management asks whether your AI infrastructure is configured correctly. This asks what it can reach. The two overlap, and configuration is part of what makes a path real, but the goal here is finding exposures rather than grading settings.
Does this replace AI guardrails or model security?
No. Guardrails and prompt filtering sit in the request path. This is the layer above.
Is this shadow AI discovery?
In effect, yes. Endpoint discovery finds the agentic apps on developer machines, Claude Desktop, Claude Code, Cursor, ChatGPT and the like, whether IT deployed them or not, together with the MCP servers and credentials configured in them. But inventory is the start, not the point. What matters is which of those hold a credential that reaches something you care about, and that is what gets qualified, owned and driven to verified closure.
How is this different from a secrets scanner?
A secrets scanner finds a credential and tells you it exists. It cannot tell you what that credential opens. Here the configuration names the target, so the connection is read rather than inferred.
Do we need an agent on developer machines?
No. Endpoint discovery is agentless, delivered through a partner integration.
Pick one AI path. We will trace it to closed.
A real one from your environment, taken from finding to verified closure, with the evidence at each step.