The scan is the easy part. You grant a read-only role to your cloud accounts, connect the identity provider, point a scanner at the GitHub organization, and a day later there is a list: SDK imports in a hundred and forty repositories, three dozen MCP configuration files, a few committed provider keys, sixty OAuth grants to AI apps, and a handful of cloud AI services nobody mentioned. The list goes into a dashboard and a weekly report. Six weeks later it is longer, and nothing about the company is safer.
Read-only access is the right way to start: it is easy to approve and cannot break anything. The failure is treating the list as the outcome. A finding is an observation; a control is something that stops an action. Between the two sit four states most programs never name, and six beliefs that keep assets stuck at the bottom. Move one consequential agent all the way up before moving everything one step.
Myth: a longer inventory means better coverage
Frameworks ask for inventories, and they are right to. NIST's Cybersecurity Framework 2.0 expects inventories of software, services and systems and of services provided by suppliers (ID.AM-02, ID.AM-04), and asks that assets be prioritized by classification, criticality and impact (ID.AM-05) [1]. The AI Risk Management Framework adds that mechanisms to inventory AI systems should be resourced according to organizational risk priorities (GOVERN 1.6) [2]. In both, the inventory is an input to prioritization. Nowhere is it the control.
Reality: three things keep a discovery list from turning into protection. The unit is wrong: a list of findings counts files and grants, while risk lives in agents, which may show up as five findings across three sources. There are only two states, discovered and protected, so every asset sits in the first until someone declares it is in the second, usually without a test. And the evidence decays: a grant revoked last week, a key rotated, a repository archived, and nothing records when a state was last true.
Myth: if a scanner found it, it is running
Reality: each read-only source establishes something specific and stops short of something else. A configuration file, an OAuth grant or a cloud resource is not evidence that the thing is running, let alone that it is controlled.
| Source | Establishes | Does not establish | Moves the asset to |
|---|---|---|---|
| SDK import or model call in code | Code at a given commit uses an AI provider | That it is deployed, or which credential it uses in production | Seen |
| MCP configuration in a repository | A server is declared for some client, with a launch command or URL | That anyone runs it, or what its tools do today | Seen |
| Committed provider key | A credential was exposed in history | That it is still valid; never test it against the provider to find out | Seen, and an immediate rotation task |
| Identity provider grant to an AI app | The app holds those scopes for those users | What data the app actually read or sent | Seen; for SaaS this may be the ceiling |
| AI provider organization key or usage | A key exists and has spent money recently | Which agent uses it, or whether that agent's calls are mediated | Seen |
| Event at your mediation point | This agent's call went through the mediation point and was decided | That there is no other path for the same agent | Observed |
Two handling rules apply to the collector itself. Store a masked form and a fingerprint of any discovered secret, never the value, so the inventory does not become the next leak. And scope the collector like any other privileged integration: OWASP's authorization guidance asks for least privilege and a periodic review for privilege creep [3], which applies to a security scanner as much as to the systems it scans.
Myth: an asset is either discovered or protected
Reality: there are six states, and each is defined by evidence that must exist and still be current. The state is a fact you can check, not a label someone assigns.
Seen, owned, routed and observed are visibility; enforced and verified protected are control. Each state requires its own current evidence, and an asset falls back a state when that evidence goes stale.
- Seen: a read-only source produced evidence that the agent exists. Most of the list lives here.
- Owned: a named person has signed an authority record that states the agent's purpose, its credentials, its worst action and who can write into its context.
- Routed: the agent's configuration points its model and tool traffic at a mediation point, such as a changed base URL, an installed hook or an MCP endpoint behind the gateway.
- Observed: the agent's own traffic, under its own identity, has reached the mediation point recently. Routed without observed usually means the configuration is not the one in production.
- Enforced: a live policy, not monitor mode, decides the agent's worst action, and the mediation point fails closed when it cannot decide.
- Verified protected: a test showed the worst action stopped on the mediated path with no downstream effect, and the same call failing on every direct path. Repeat the test on a schedule and after every change.
Two rules keep the states honest. An agent sits at the highest state whose evidence is current, so an agent that sends no traffic for a month drops from observed to routed, and one whose verification test is three months old drops from verified to enforced. And a state applies to a scope: a coding agent can be verified for shell commands and only seen for its browser tool. Record the scope next to the state.
Myth: the fastest progress is everything in monitor mode
Reality: moving the whole estate to routed in monitor mode turns the dashboard green and protects nothing. Collapse findings into agents first, joining them on stable identifiers: the credential's fingerprint, the repository and deployment that use it, the cloud role and the identity tenant. Keep uncertain matches as hypotheses rather than merging them; two services named support-bot are not necessarily one agent. Drop anything that only reads and summarizes for a person. Rank the rest by worst action and exposure to untrusted input, and take the top agent through every state before you start the next.
At Fennick Labs, a fictional software company of about 600 people, a first scan returned roughly 280 findings, which collapsed into about 70 candidate agents and apps, 23 that could act, and nine that combined a consequential action with untrusted input (figures illustrative). The team started with a billing support agent that issues account credits and reads customer tickets, and within two weeks it was verified protected for credits and outbound email.
Myth: every asset reaches enforcement the same way
Reality: each kind of asset has its own shortest route from owned to verified, and a different direct path to close. Pick the route by what the asset is, not by which source found it.
| Asset | Shortest route to enforced | Direct path to close | Verification test |
|---|---|---|---|
| Custom agent calling a model API | Change its base URL to the mediation point and give it its own key; route its tool and MCP calls the same way | The provider key it used before; rotate it and remove it from the deployment | Steer it to its worst action and confirm no downstream change; then repeat with the old key and confirm the call fails |
| Coding agent on developer machines | Install pre-tool hooks through a managed configuration that users cannot edit | Unmanaged installs and settings that disable hooks | Run a destructive command through the agent and confirm it asks or is refused on a managed machine |
| MCP server declared in repositories | Serve it through the mediation point with an approved, pinned tool list | The same server URL or launch command in other configuration files | Call a tool outside the approved list and confirm it is held |
| SaaS AI feature with an identity grant | Reduce the grant's scopes and users; use the vendor's admin controls and audit logs | None you control at runtime; record it as governed by grant, not runtime-enforced | Confirm the reduced scopes in the identity provider and that removed users lose access |
| Committed or leaked provider key | Revoke it at the provider, then move whatever used it onto the custom-agent route | Copies in git history, CI variables and laptops | Confirm in the provider's console that the key is revoked; never call the API with it to check |
| Cloud AI service in your account | Limit who can invoke it to the agent's role, and route that agent's calls through the mediation point | Other principals with invoke permission | Invoke it with an unauthorized principal and confirm it is denied |
Ask for authority one stage at a time. Discovery needs read access; enforcement for a custom agent needs a configuration change its owner makes, not security-team write access to production. Least privilege [3] applies to your own integrations too.
Myth: routed means protected
This is the most common false claim of coverage. The application was pointed at the gateway, traffic shows up, the dashboard turns green, and the provider key the agent used last month is still valid in three places. Any prompt injection that reaches the agent's code path, any engineer debugging locally, and any script that copied the key can skip the control.
The agent reaches the model or tool through the gateway, where its worst action is stopped, and also directly with an old provider key. It counts as verified protected only when the second test fails as well.
Reality: OWASP's Excessive Agency guidance calls for complete mediation, enforcing authorization in downstream systems rather than relying on the model to decide [4], and OWASP's authorization guidance adds that permission should be validated on every request and access denied by default [3]. In coverage terms, every path to the consequential action has to go through a decision, and every path that does not has to fail. Run three tests for each agent and scope:
- A permitted task completes through the mediated path, so you know enforcement did not break the work.
- The agent, steered toward its worst action, is stopped, and the downstream system shows no change.
- The same call made with the agent's previous credential, or from outside the mediated path, fails at the provider or the network.
Then keep discovery running against the protected estate. Runtime traffic from a principal the inventory does not know is a coverage gap. An inventory agent with no runtime traffic is dormant, misconfigured or using another path. A new provider key next to a verified agent is the start of a bypass. Each discrepancy is a work item, not a reason to edit the dashboard.
Myth: coverage is a percentage
Reality: coverage is a count per state over a denominator you can name, meaning the agents found in the cloud accounts, repositories and identity tenants you actually scan, with the sources you do not yet scan listed beside it. “Nine priority agents: four verified protected, three enforced, two owned; sources not yet connected: one cloud account and the marketing team's SaaS tools” is a sentence a CISO can act on. “AI coverage 71%” is not.
- Track time in state. An agent that has been owned for six weeks without being routed is stuck, and its owner should know.
- Show stale evidence separately. A verified agent whose test is overdue is not verified until it is rerun.
- Keep SaaS apps governed by grants in their own row, so they are neither hidden nor counted as runtime-enforced.
Where Intertrace sits on this route
Intertrace's discovery is read-only: it scans cloud accounts, GitHub repositories (MCP configurations, committed keys, AI usage in code and CI), identity providers' AI-app grants and AI provider organization keys, opens findings as work items, and stores keys only as a masked form and a fingerprint. The gateway sits inline, with tenancy derived from each agent's runtime key, and records every decision as a structured event, which is the evidence for observed and enforced. Approved MCP servers have their tool lists pinned, and the first call to an unapproved server asks once. Rotating old provider keys and restricting egress remain changes your teams make.
Run the old-key test on Monday
Take the agent your dashboard is proudest of, one that is routed and observed. Steer it toward its worst action through the mediated path and confirm the downstream system shows no change. Then make the same call from outside that path with the provider key the agent used before. If the second call succeeds, the agent is observed, not protected, and you have this week's work: rotate the key, remove it from the deployment, and run both tests again. While you are at it, rotate every committed key the scan found, without using any of them to check whether they still work.
