C17 New in v1.3 Layer 1 - Identity & Integrity

Agent Discovery and Shadow AI Detection

Continuous discovery of ungoverned agents across the environment. Three detection mechanisms (network observation, cloud asset inventory, workload identity classifier) feed candidates into the C04 lifecycle for enrol-or-terminate remediation. Closes the assumption that the C01-C16 control plane has anything to say about agents it has never seen.

Placement rationale

C17 sits in Layer 1 alongside C04 because it is an inventory and identity-boundary control. C04 governs the lifecycle of agents that have entered the control plane; C17 governs the act of getting them into the control plane in the first place. The two controls share an evidence stream: a discovery event in C17 either resolves to a C04 Commission record (the agent is enrolled) or a termination record (the agent is removed). C17 is the feeder, C04 is the receiver.

Why

Without this control, an organisation can operate GATE-conformant agents inside a control plane while an unknown number of ungoverned agents run elsewhere in the same environment, calling the same enterprise tools through workload identities that GATE never sees. The failure mode is invisible coverage loss: the C01-C16 evidence stream attests to the agents the platform knows about and tells you nothing about the agents it does not.

This happens through several routes. An engineer integrates an LLM into an existing service and the service's workload identity starts making tool-shaped calls without ever being declared an agent. A vendor SaaS product activates an "AI agent" feature that calls back into customer infrastructure. A platform team enables a managed-agent capability inside a cloud account that was not part of the original GATE rollout. In each case the existing GATE controls behave correctly within their scope - they were never asked to govern the agent - while the organisation's risk posture changes silently.

Prompt-based constraints fail here for the same reason they fail elsewhere: the agent is not asking the GATE control plane for permission. Conventional application logging fails because the workload identity making the calls looks like a service, not an agent, and service identities are not subject to ABOM verification or lifecycle review. Network-level egress monitoring catches the call but not the intent: it cannot distinguish a deterministic API client from a model-driven agent making the same call.

What

A discovery and classification service that operates outside the GATE control plane and feeds candidates into it. The control consists of three mechanisms operating at three boundaries:

  1. Network boundary detector - observes outbound traffic from workloads inside the governed environment, looking for call patterns characteristic of agentic behaviour: bursts of structured calls to LLM inference endpoints (OpenAI, Anthropic, Bedrock, Vertex, on-prem inference services), tool-shaped API call patterns from workload identities that are not present in the C04 inventory, and chained inference-to-tool-call sequences within a single workload identity.
  2. Cloud asset inventory integrator - consumes AWS Config, Azure Policy, GCP Asset Inventory, and equivalent cloud-native asset feeds to identify newly provisioned compute, container, or function workloads whose IAM role attaches permissions to invoke inference endpoints or to call tools listed in the Tool Gateway tool registry.
  3. Workload identity classifier - compares the set of identities making calls through enterprise tool APIs against the set of identities present in the C04 inventory. Identities that appear in the tool stream but not in the inventory are classified as candidates and emitted as discovery events.

For each candidate, the control produces one of three outcomes:

  • Enrol - route the candidate into C04 Commission.
  • Terminate - revoke the workload identity and block its network paths.
  • Accept with justification - the candidate is verified non-agentic and recorded as an exception with TTL.

Invariants the control guarantees:

  • Every workload identity that makes a call to a registered tool endpoint produces either a C04 lifecycle record or a C17 exception record with a non-expired TTL. There is no third state.
  • Discovery events are immutable and tamper-evident (C11 ledger).
  • The classifier's training or rule set is versioned, signed (C03), and hashed into the discovery event so a discovery decision can be replayed (C10).

How

Control-plane flow

The discovery service runs continuously outside the agent runtime. On each interval it emits zero or more agent.discovered events. Each event carries the candidate's workload identity, the boundary that detected it, the classification confidence, the evidence that triggered detection, and a candidate hash. The C04 lifecycle service consumes discovery events. If the candidate is already known (workload identity matches a Commissioned agent), the event is dropped after evidence retention. If unknown, the lifecycle service opens a Commission ticket against the candidate's owner (resolved via cloud asset tags, billing tags, or a fallback owner) and clocks a remediation TTL. On TTL expiry without enrolment, the control invokes the termination path: identity revocation through the IdP, deny rule injection into the Tool Gateway for the candidate's identity, and network egress blocking via cloud-native network policy.

Deployment

Run the network boundary detector as a passive observer on egress flow logs (VPC Flow Logs, NSG Flow Logs, GCP VPC Flow Logs) and on the API mediation layer of the Tool Gateway itself. The asset inventory integrator runs as a scheduled job consuming cloud-native asset feeds and writing to a normalised candidate store. The classifier runs as a streaming job comparing the candidate store against the C04 inventory. All three feeds publish to a single gate.discovery topic that the lifecycle service subscribes to.

Safe rollout

Begin in observe-only mode for thirty days. During this period the control emits discovery events and opens C04 Commission tickets, but the termination path is disabled. This baseline establishes the false-positive rate and the candidate population's true size, both of which are often much larger than the platform team expects. After observe-only, promote to enforce mode for new candidates only (existing unenrolled identities continue under the observe path while their owners catch up). Promote to full enforce, including for pre-existing candidates, only after the false-positive rate is below a documented threshold and the owner-resolution path is reliable.

Integration with C04

C17 discovery events are inputs to C04. The C04 Commission state machine adds a new entry state: Discovered (a candidate that has been detected but has not yet been classified or remediated). Discovered transitions to Commissioned on enrolment or to Terminated on TTL expiry. No agent can move directly to Run without traversing Discovered or being Commissioned via a declared path.

Evidence

  • agent.discovered event per candidate: timestamp, candidate workload identity, detection boundary (network, asset, identity), classification confidence, evidence payload, classifier_bundle_hash, candidate_hash, trace_id.
  • agent.remediation_outcome event per candidate: timestamp, candidate_hash, outcome (enrolled, terminated, exception), owner identity, time-to-remediation, exception_id and TTL where applicable.
  • Classifier coverage metric: % of governed-environment workload identities scanned per observation window. Must reach 100% within a documented detection window (recommended: 24 hours rolling).
  • Reconciliation metric: count of identities present in the tool API stream but not in the C04 inventory, computed daily, with target zero outside the active remediation TTL window.
  • Termination proof: revocation event from the IdP, deny rule version in the Tool Gateway, network policy version, all tied to the agent.remediation_outcome event.
  • Classifier integrity report: signed classifier bundle hash matches the hash recorded in discovery events.

Failure modes

  • Network detector blind spots. Deploying the detector only on outbound egress and missing intra-VPC inference services. Agents that call a local LLM service inside the VPC produce no egress signal. Mitigation: instrument the Tool Gateway's own ingress as a detection point so any call to a registered tool that lacks a corresponding C04 identity is itself a discovery signal.
  • Owner resolution gaps. Cloud assets without billing tags or owner tags produce candidates that cannot be routed for remediation. They sit in Discovered indefinitely. Mitigation: enforce a tagging policy as a precondition for asset creation in the governed environment, and treat untagged candidates as immediate-termination by default at high_privilege.
  • Observe-only drift. The control is deployed in observe-only mode and never promoted because the candidate backlog is too large. Mitigation: a documented promotion criterion tied to backlog size, not time, and an executive escalation path if the backlog cannot be drained within a defined window.
  • Exception abuse. Accept-with-justification exceptions are issued routinely to avoid the remediation effort. The exception list grows without bound. Mitigation: exceptions carry a TTL that the lifecycle service enforces; exceptions expire and re-trigger discovery; the count of active exceptions is a tracked compliance metric.
  • Classifier evasion. An unenrolled agent learns the classifier's signal patterns and behaves below detection thresholds. Mitigation: the classifier rule set is private (not shipped to agent runtimes), and the network detector relies on multiple orthogonal signals rather than any single signal.
  • Vendor-managed agents. SaaS products with AI features call back into the customer environment from outside the customer's network. The network detector cannot see them. Mitigation: vendor inbound calls are mediated through a designated Tool Gateway tenant; calls from outside that tenant are denied at the perimeter.

NIST AI RMF alignment

C17 maps to GOVERN and MAP. GOVERN: implements GV-1.6 (mechanisms exist to inventory and account for AI systems) and GV-4 (organisational accountability structures). MAP: implements MP-1.1 (context of use is established for AI systems) by ensuring that no system in operational use is outside the inventory scope. The control complements C04's GOVERN function by extending it to systems that have not yet self-declared.

ISO/IEC 42001 alignment

C17 maps to A.6.2.2 (AI system inventory) and A.6.1.1 (AI system identification). It also supports clause 8.1 (operational planning and control) by ensuring that operational controls apply to the full population of AI systems, not only the declared population. Typical evidence produced: discovery and remediation logs, exception register with TTLs, inventory reconciliation reports.

Contents
On this page
All controls