Skip to content

Enterprise deploymentFully managed today; customer-hosted available as a pilot.Contact salesView pricing

Read-only discovery is the beginning of protection

Guide · Published October 17, 2026 · 6 min readBy Intertrace — Security engineering
Shadow AIDiscoveryRuntime enforcement
Read-only discovery is the beginning of protection — explanatory control diagram
Reference architecture for the controls discussed in this guide. Adapt the boundaries to your deployment.

Series date: October 15, 2026. First published October 17, 2026. Series dates sequence this editorial collection.

What read-only integrations can prove, where their visibility ends, and how to move from an evidence-backed AI inventory to verified runtime enforcement.

IntertraceSecurity engineering

Plain-language guidance for teams adopting AI — the risk, the cost, the compliance, and what to ask before you buy.

Guide · October 17, 2026 · 6 min read

The easiest security integration to approve is often the one that cannot change anything. A read-only cloud role, identity connector, or repository scan can produce useful evidence quickly. It can identify an AI service, an OAuth grant, an SDK dependency, or a committed configuration. That makes it an excellent entry point for an AI security program.

It does not follow that the discovered workload is now protected. Discovery observes a system through a particular source. Enforcement must control an actual path to a consequential action. Conflating those two states creates a dangerous dashboard: the inventory grows, the coverage indicator turns green, and the direct execution path remains untouched.

State exactly what the source establishes

A repository import establishes that a configuration or code reference existed at a particular revision. It does not establish that the code was deployed or executed. An identity grant shows that an application received permissions in an identity system. It does not reveal every prompt sent to that application. A DNS observation can indicate contact with a known AI domain without revealing the content or the responsible agent.

Preserve the original observation, collector identity, collection time, and scope. Separate provider-reported facts from deterministic deductions and model-generated hypotheses. An analyst can then distinguish an active provider account from an inferred agent found in a sample repository. Neither should be discarded; they should carry different evidentiary weight.

Inventory freshness is also a property of the source. A connector that has not refreshed for a week cannot support a claim about current permissions. Display missing coverage and collection errors next to the asset. Absence from one feed is not evidence that an AI system does not exist.

Model relationships before assigning risk

A list of model names is a weak security inventory. The useful unit is the execution relationship: an owner deploys a workload, the workload uses a principal, the principal reaches a connection, and the connection grants access to resources. A new model provider may have little immediate consequence; a familiar agent with a newly privileged connection may have substantial consequence.

Resolve identities conservatively. Two assets sharing a display name are not necessarily the same workload. Correlate stable provider identifiers, repository and deployment links, tenant boundaries, and observed runtime identifiers. Preserve uncertain matches as hypotheses rather than merging them into false certainty.

Risk should point to a concrete intervention. An exposed credential needs rotation and investigation. An unowned application needs an accountable owner. A privileged agent needs a reviewed access boundary. A gateway bypass needs a routing or credential change. A single numerical score cannot replace these distinct actions.

Evidence and its limits
ObservationSupportsDoes not establish
Repository MCP configurationDeclared server and revisionCurrent process execution
Identity application grantGranted provider permissionsActual data disclosure
Cloud AI resourceResource presence and configurationAll callers and sessions
Gateway execution eventA particular mediated requestCoverage of direct bypass paths

Use explicit coverage states

Discovered, connected, observed, and enforced should be different states. Discovered means a source produced evidence. Connected means an integration or routing configuration exists. Observed means actual traffic has arrived with a resolvable identity. Enforced means the relevant action path has an active control whose behavior has been verified.

Even enforced needs a scope. A model gateway can inspect the prompts and responses routed through it. If the application executes a returned tool call locally, the gateway may not see the actual execution or its result. Tool protection requires an execution hook, mediated MCP path, controlled credential broker, or downstream authorization mechanism that the workload cannot bypass.

A useful coverage record names the protected operation, enforcement point, last verification time, and known alternate routes. A connected ChatGPT or Copilot inventory source should not be represented as inline inspection of every conversation. The source may provide administrative visibility while the SaaS application remains outside the gateway path.

Design the shortest route to a verified boundary

After discovery, offer a resource-specific protection plan. For a developer agent, that might mean installing a supported permission hook and verifying its host configuration. For a service agent, it could mean routing model and MCP traffic through managed endpoints and restricting direct provider access. For an identity-connected SaaS product, the practical intervention may be reducing grants and improving administrative monitoring.

Minimize the credential request for each stage. Discovery should not ask for write permissions merely because remediation might eventually need them. When a change is necessary, request the exact additional authority or let the customer apply a generated configuration. This makes the permission increase understandable and reviewable.

The integration should verify its own claim. Send a benign permitted request, a deliberately prohibited request, and an identity-mismatch request in an approved test environment. Confirm the downstream effect as well as the gateway verdict. A response labeled blocked is insufficient if the provider still executed the action through another route.

Keep read-only collection safe

Read-only access can still expose sensitive information. Repository collectors may encounter credentials, customer data, and proprietary code. Cloud inventory responses can reveal architecture. An identity feed can disclose employees and privileged applications. Collect the minimum necessary fields, restrict access to the resulting inventory, and set an explicit retention policy.

Prefer storing a masked indicator and a one-way fingerprint for discovered secrets. Avoid replaying or validating a live credential against a provider merely to prove it exists. A finding can be useful without increasing exposure. Make any active validation a separately governed operation with a clear owner and scope.

OWASP's authorization guidance recommends least privilege and checking permission at every request [2]. Those principles apply to the security collector itself. Tenant isolation, connector scoping, and reliable offboarding deserve the same attention as the systems being scanned.

Report progress as evidence, not asset counts

Start with a denominator the team can defend: the workloads observed in selected cloud accounts, identity tenants, repositories, and network sources. Report which sources are missing. Show how many high-consequence paths have a named owner, reviewed access, and a tested enforcement point.

Reconcile discovery and runtime feeds continuously. An inventory asset with no traffic may be dormant or misconfigured. Runtime traffic from an unknown principal may indicate a coverage gap. A disappearing grant may reflect successful remediation or a broken connector. Each discrepancy deserves context before it changes the coverage claim.

The first useful outcome is a small, accurate map of authority and exposure. The next is one verified control on a path that matters. Read-only discovery reduces the friction of starting; precise enforcement claims preserve trust as the program expands.

Sources

Reporting and research this piece draws on. Links are to third-party sources; Intertrace commentary is our own.

  1. 1.AI Agent Security Cheat Sheet — OWASP
  2. 2.Authorization Cheat Sheet — OWASP

Continue reading

← Back to blog