Agent Control Plane Reference Guide

Implementation Controls for Governed Runtime Actors

A companion implementation guide to Agent Architecture and the Enterprise Control Plane

Arqua Reference Guide

Reference Guide v0.1 | July 2026

Mark Tovey, Arqua Pty Ltd

A registry records legitimacy. A contract enforces legitimacy. A run record proves what happened. An evidence bundle supports reconstruction. Lifecycle state determines whether the agent may still exist.

The minimum viable Agent Control Plane is not a platform procurement exercise. It is a legitimacy proof for an enterprise runtime actor.

Download the reference guide

Title: Agent Control Plane Reference Guide

Subtitle: Implementation Controls for Governed Runtime Actors

Guide type: Arqua Reference Guide

Version/date: Reference Guide v0.1 | July 2026

Download PDF: PDF forthcoming

Parent paper: Agent Architecture and the Enterprise Control Plane

CTA: Request a Briefing

Purpose and scope

This guide is the operational companion to Agent Architecture and the Enterprise Control Plane. The paper explains why enterprise agents must be governed as runtime actors. This guide describes the control objects, fields, gates, metrics, review questions and failure modes needed to implement that architecture for one material agent or agent-enabled flow.

The guide is intended for enterprise architecture, AI governance, Responsible AI, agent platform, identity, security, data governance, observability, cost-management and operational-risk teams.

The guide is technology-neutral. It can be implemented across internal agent platforms, vendor-hosted agents, embedded SaaS copilots, workflow automations, cross-domain knowledge agents and execution agents.

Control objective

Can the enterprise prove, for each material agent run, that the agent was registered, authorised, operating within approved purpose, using permitted data and tools, constrained by applicable policy, monitored at runtime, within lifecycle and reconstructable after the fact?

Guide structure

1. Governing object model
2. Agent classification model
3. Agent Registry / Agent CMDB
4. Agent Control Contract
5. Runtime enforcement gates
6. Effective actor resolution
7. Runtime surfaces and boundaries
8. Agent Run Record
9. Agent Evidence Bundle and evidence governance
10. Observability, evals and monitoring
11. Security monitoring and operational resilience
12. Token usage, AI FinOps and value control
13. Lifecycle states, recertification and offboarding
14. Cross-domain, vendor and embedded agents
15. Multi-agent and orchestrated-agent systems
16. Execution agents and consequence controls
17. Maturity model
18. Category metrics
19. Adoption pattern
20. Failure modes
21. Architecture review questions
22. Minimum viable control checklist

1. Governing object model

Accepted Agent Architecture → Agent Registry → Agent Control Contract → Runtime Enforcement → Agent Run Record → Evidence Bundle → Lifecycle Review

The governing object model links accepted agent architecture to registry legitimacy, runtime contract, enforcement, evidence and lifecycle review.

2. Agent classification model

assist → delegate → participate → coordinate → execute

Agent types include personal productivity agents, worker-delegated agents, role-delegated agents, process-owned agents, cross-domain agents and execution agents. Each type carries a different authority source and minimum control burden.

3. Agent Registry / Agent CMDB

The registry records agent legitimacy. It is not merely an inventory. It is the authoritative control surface for agent identity, ownership, authority, scope, risk, permitted use, runtime obligations and lifecycle state.

Most critical fields: authority_source, delegation_scope, permitted_data, permitted_tools, permitted_actions, lifecycle_state and offboarding_trigger.

4. Agent Control Contract

The Agent Control Contract binds the registered agent to runtime. It is the versioned, machine-readable and enforceable expression of accepted agent architecture.

A registry without runtime binding becomes inventory. A contract without registry authority becomes configuration. The Agent Control Plane requires both.

5. Runtime enforcement gates

A control plane is not merely a record of governance. It must shape runtime behaviour.

Enforcement gates include launch, authority, retrieval, prompt assembly, model routing, tool-use, memory, output, execution and cost gates.

Without enforcement points, the Agent Control Plane becomes a reporting layer rather than a control plane.

6. Effective actor resolution

The effective actor in an agent run is the compound of agent identity, control-contract version, initiating user or process, authority context, purpose, task, environment and lifecycle state.

effective_actor = agent_id + contract_version + initiating_context + authority_context + purpose + task + environment + lifecycle_state

Effective actor resolution prevents permission amplification. A worker may have access to data that a delegated agent is not permitted to use for a particular task.

7. Runtime surfaces and boundaries

An agent is a runtime bundle, not a model endpoint. Agent versioning must cover model, prompt, tool schema, retrieval source set, embedding model, index version, memory policy, orchestration logic, routing policy, safety filter, permitted-use policy, human review threshold, action permission, evaluation suite and deployment environment.

8. Agent Run Record

Every material agent run should produce an Agent Run Record. For high-consequence use, the run record becomes part of the evidence basis for decision reconstructability.

The run record should capture identity, version, user or process context, effective actor, authority source, purpose, input reference, retrieved sources, semantic context, policy version, prompt version, model version, tools called, memory access, output classification, human review, proposed or triggered action, execution admissibility reference, outcome, cost, eval result and incident flag.

9. Agent Evidence Bundle and evidence governance

The Agent Evidence Bundle assembles evidence required to reconstruct a material agent run, agent-influenced decision, incident or action. Reconstructability does not always mean exact replay. The objective is to preserve enough evidence to explain what happened, test conformance and understand what consequence was influenced.

Agent evidence should be sufficient for assurance, but governed as sensitive enterprise evidence.

10. Observability, evals and monitoring

Agent monitoring requires application performance monitoring, security monitoring, agent observability, evals, Responsible AI governance, registry context and control-contract context.

Required capabilities include trace capture, prompt and instruction observability, retrieval lineage, tool-call tracing, agent run history, evaluation datasets, regression testing, quality scoring, failure analysis and human feedback loops.

11. Security monitoring and operational resilience

Security monitoring should cover suspicious access, prompt injection, tool misuse, credential misuse, policy violations, data exfiltration, high-risk API calls, anomalous user behaviour, cross-boundary leakage, memory poisoning, retrieval poisoning, tool-chain manipulation, authority laundering and execution bypass.

12. Token usage, AI FinOps and value control

Agent cost control should track token usage, cost per agent, user, business unit, use case, model, environment, successful task, failed run, retrieval, embedding, tool execution and evaluation.

Controls include budgets, quotas, rate limits, alerts, cost attribution, showback or chargeback, model routing, environment limits, high-cost query detection and kill switches.

Cost anomalies are behavioural signals. Unexpected token growth, retrieval expansion, tool-call loops or evaluation spikes may indicate prompt injection, workflow failure, misuse, model drift, poor design or runaway automation.

13. Lifecycle states, recertification and offboarding

Lifecycle states include proposed, approved for sandbox, pilot, production, restricted, suspended, deprecated, retired and archived.

Lifecycle state must be enforced at runtime. A suspended or retired agent must not be callable merely because its endpoint still exists.

No agent should survive the authority from which it derives legitimacy unless that authority is explicitly renewed, transferred or reapproved.

14. Cross-domain, vendor and embedded agents

A cross-domain agent is an institutional interface. It carries meaning, policy, provenance and authority across boundaries. It requires registered identity, clear purpose, approved sources, retrieval boundaries, semantic context rules, source citation, usage monitoring, cost tracking, evals, human feedback, Responsible AI review and incident handling.

An agent does not escape governance because it is packaged as a feature in another product.

15. Multi-agent and orchestrated-agent systems

Enterprise agent architecture will increasingly involve orchestrators, specialist agents, sub-agents and tool-using agent chains. This creates a delegation-chain problem. The Agent Control Plane must preserve the chain of authority, not merely the final output.

Agent-to-agent delegation must not create authority that neither agent independently possesses.

16. Execution agents and consequence controls

Recommendation is not decision.
Decision is not execution.
Execution requires admissibility at the point consequence binds.

Execution agents require explicit execution authority, runtime state checks, policy checks, authority checks, semantic binding, human review where required, non-bypassable boundaries, evidence bundles and feedback loops.

17. Maturity model

The critical transition is from governed pilots to a coordinated Agent Control Plane. At the lower level, the enterprise has agent controls. At the higher level, the enterprise has an Agent Control Plane.

18. Category metrics

Category metrics include coverage metrics, runtime conformance metrics, lifecycle metrics and outcome metrics. Examples include agent registration coverage, ownership coverage, authority-source coverage, runtime trace coverage, control-contract coverage, execution admissibility coverage, recertification compliance, offboarding compliance, ghost-agent count, agent reconstructability rate, incident rate, human override rate and accepted recommendation rate.

19. Adoption pattern

Start with one material agent. Classify the boundary type. Register the agent. Define the Agent Control Contract. Define authority and permitted use. Define runtime enforcement. Define runtime evidence. Define evals and monitoring. Define cost controls. Define lifecycle controls. Link execution controls. Close the feedback loop.

20. Failure modes

Failure modes include agent sprawl, ghost agents, delegation collapse, authority collapse, provenance loss, policy evaporation, runtime non-conformance, cost runaway, evaluation gaps, tool overreach, memory persistence risk, cross-domain context collapse, multi-agent authority laundering and execution bypass.

21. Architecture review questions

Use the guide to review identity and ownership, scope and authority, effective actor, data and permitted use, runtime enforcement, observability, security and cost, conformance and feedback, execution and consequence, and multi-agent or vendor-agent governance.

22. Minimum viable control checklist

The minimum viable control checklist asks for evidence of what the agent is, who owns it, what authority it derives from, what it may do, what data it may use, what runtime contract binds it, what model and prompts it uses, what monitoring applies, what evals apply, what it costs, what human review applies, what happens when authority ends, and whether it can be reconstructed.

End of Agent Control Plane Reference Guide. Reference Guide v0.1.