An AI agent control plane is the system that discovers agents and models, binds them to projects and declared intent, enforces reachability and sessions outside agent write control, manages credentials, preserves evidence, and executes containment. Securing agents built on open-weight models takes more than a model registry and an inference gateway, and evaluating a control plane means testing where the assembled parts leave seams, because agent incidents travel through seams: the discovery that does not talk to the policy engine, the network control that cannot see the process, the log store the agent can reach, the quarantine that a reinstall escapes.
The fourteen tests
For each criterion: the question to ask, the evidence or proof-of-concept test that answers it, and the answer that disqualifies.
| # | Criterion | Ask | Evidence or POC test | Disqualifying answer |
|---|---|---|---|---|
| 1 | Agent and model discovery | Can it see the process, not just the traffic? | Launch an agent against a loopback model on an enrolled endpoint; it appears in inventory with process and artifact hash | Discovery is traffic-based only |
| 2 | Identity and project binding | Is every agent a verified identity bound to a project? | Inventory shows agent identity, not a shared service account | Agents act as the logged-in user, unbound |
| 3 | Declared scope | Is authorization a versioned, reviewable artifact? | Produce the declaration for a running agent: destinations, tools, limits, approvals | Policy lives in system prompts |
| 4 | Enforcement independence | Does enforcement run outside the agent's write control? | Modify, replace, or relaunch the agent; authorization still holds, and attempted disablement of the enforcement component is detected and handled by policy | Enforcement depends on an SDK or hook the agent calls |
| 5 | Capability-matched enforcement | Does it enforce or integrate at the correct layer for each capability? | Map each declared capability to its layer: network, session, OS, process | One chokepoint claims to govern everything |
| 6 | Reachability isolation | Are out-of-scope resources absent, not denied? | Connectivity probing confirms no usable route to out-of-scope resources, not merely an application-layer denial | Cross-project resources reachable but filtered |
| 7 | Credential boundary | Do enterprise keys stay off endpoints? | The ten-minute test: inspect env, config, and process memory during an active governed session; full proof adds packet capture, injection trace, and provider-side logs | A reusable provider key is present at use |
| 8 | Local session inspection | Can inspection and evidence remain fully local where custody policy requires? | Show the inspection point and where its traffic and records live | Local custody is unavailable; prompts or logs must transit a vendor cloud |
| 9 | Evidence integrity and custody | Is the record attributable, tamper-evident, governed, proportionate? | Sample record with identity, hash, config and policy versions; storage the agent cannot reach | Agent-writable logs, or content depth is all-or-nothing |
| 10 | Agent-specific containment | Can it stop the agent without isolating the machine? | Contain a misbehaving agent; user keeps working; restart comes back contained | Response is EDR endpoint isolation |
| 11 | Model recall | Can it narrow every consumer of a suspect hash? | Tabletop: hash to affected agents to fleet narrowing, timed against a 15-minute target | Affected population cannot be enumerated |
| 12 | Lifecycle retirement | Does decommissioning revoke everything and retain the record? | Retire a test agent: identity, credentials, reachability gone; record marked retired | Retirement is deletion, or leaves reach behind |
| 13 | Failure behavior | What happens when the enforcement point is down? | Take the enforcement point offline; behavior follows an explicit, tested availability policy, and protected credential paths fail closed | A fallback path delivers raw keys or open egress |
| 14 | Integration | Does evidence flow to the SOC? | Policy events and records land in the SIEM with the schema intact | Evidence is trapped in the product console |
How to run it
Three stages, in order, because each is cheaper than the next. Paper first: the declaration artifact, a sample evidence record, and the capability-to-enforcement map are documents a vendor either has or does not. Live POC second: tests 1, 6, 7, and 10 take an afternoon in a lab enclave and separate architecture from slideware. Failure drills last: tests 11 and 13 are rehearsals of the two worst days, the bad-model disclosure and the control-plane outage, and a vendor's willingness to run them is itself evidence.
Score it honestly against your own assembled alternative too. A team can build parts of this from network policy, an artifact registry, a secrets manager, and endpoint tooling; the fourteen tests apply identically, and the seams between assembled parts are where the disqualifying answers tend to live.
Where Ensage fits
Ensage AI maps this operating model to an integrated control plane: process-level agent visibility through zLink, project-scoped enclaves on the CoIP Platform overlay, Virtual Chamber protection for high-value assets, the AI Session Controller as the local session and credential boundary, and zCenter for policy and evidence. Run the fourteen tests against it; test 7 takes ten minutes.
Related:
- Open-weight model security (pillar)
- Enterprise model recall playbook
- Local LLM security and discovery
- MCP server security
- AI agent guardrails and declared authorization
- Credential substitution for AI agents
- AI agent containment versus endpoint isolation
- Secure a self-hosted LLM inference server
- Evidence-grade audit logging for self-hosted AI agents
- LLM output validation for open-weight deployments
