Your Agents Need a Chain of Command

The organisations that govern AI agents well aren't the ones that move fastest. They're the ones that answered the chain of command questions before the first deployment — and kept answering them as the scope grew.

This isn't a developer problem. Developers can configure an agent in an afternoon. What most organisations are missing is the governance layer: who authorised this, what is it allowed to do, and who is accountable when it does something unexpected. Those questions don't answer themselves, and they don't get easier after the fact.

What is an autonomy level, and why does it determine your risk exposure?

Coder's whitepaper on operationalising AI agents in regulated industries describes four levels of agent autonomy. At Level 1, the agent makes suggestions — a human reviews and executes every action. At Level 2, the agent performs defined tasks but pauses at key checkpoints for human review. At Level 3, the agent operates independently within explicit boundaries and escalates anything outside them. At Level 4, the agent completes full workflows with minimal human interaction.

Most enterprise deployments are designed for Level 2 but drift toward Level 3 behaviour over time — without updating the governance structures to match. The agent starts handling more cases, running more autonomously, touching more systems. Nobody makes a deliberate decision to move up a level. It just happens. That gap between intended and actual autonomy is where the risk accumulates.

What breaks when agents don't have a defined chain of command?

The three most common failure patterns are permission sprawl, silent failure, and attribution gaps.

Permission sprawl occurs when an agent is granted access to everything it might need rather than only what it needs. Every unnecessary permission is an attack surface. NIST's AI Risk Management Framework is explicit on this point: least-privilege access applies to automated systems just as it does to human users, and the burden of justification runs in both directions.

Silent failure is subtler. If an agent encounters a blocked action and simply stops — without logging or surfacing what happened — you have no operational visibility and no audit record. You don't know what was attempted. In a regulated environment, that gap is a compliance problem before it's a security problem.

Attribution gaps close the loop. If every agent action isn't logged with full attribution — what ran, what it accessed, what it changed, under whose authorisation — your compliance function cannot audit it with the same rigour applied to human actions. For Canadian organisations, this is not an abstract concern: PIPEDA requires accountability for all personal information accessed or processed on an organisation's behalf — an obligation that extends to automated systems acting as agents of that organisation. And if it cannot be audited, it cannot be defended. The EU AI Act codifies this expectation for high-risk systems: operators must maintain logs sufficient for post-deployment auditability — an obligation that begins at deployment, not after an incident.

How do you design governance before the first deployment?

Identity comes first. The agent should have its own credentials, its own permissions, and its own audit log — separate from any human developer or shared service account. This isn't security hygiene for its own sake. It's the foundation of accountability.

Boundaries come second. Network access should be restricted to what the task actually requires. The agent should not write to protected branches or production systems without an explicit approval step for high-stakes actions. Equally important: the agent should be told its boundaries explicitly, not just blocked by them silently. An agent that understands its limits behaves more predictably than one that discovers them by running into them.

Auditability comes third. Every action logged. The security team briefed and signed off. The compliance team able to audit agent actions with the same rigour as human actions. For Canadian public sector organisations, the Treasury Board Directive on Automated Decision-Making sets explicit requirements for algorithmic transparency, impact assessments, and human oversight mechanisms — requirements that extend directly to AI agents operating within those systems. For private-sector organisations, Canada's voluntary Code of Conduct on the Responsible Development and Management of Advanced Generative AI Systems sets the equivalent expectations: transparency, human oversight, and the ability to explain and audit what an AI system does. An incident response plan must be in place before anything goes live — because agents will occasionally behave unexpectedly, and the question is whether you're prepared when they do.

Readiness comes fourth. Give the agent structured context before it starts, rather than letting it begin cold. Run a pilot on a low-risk use case before expanding scope. Define your success metrics before deployment, not after. These aren't perfectionist constraints — they're the sequence that separates a controlled rollout from a reactive one.

What should a pre-deployment review actually include?

Each area has a set of binary questions. Either the agent has its own identity, or it doesn't. Either high-stakes actions require explicit approval, or they don't. Either an incident response plan exists, or it doesn't. That binary framing is intentional — a pre-deployment review isn't a risk assessment; it's a readiness check.

The OECD Principles on Artificial Intelligence make a similar point about accountability: organisations deploying AI systems must be able to explain and justify those systems' decisions, and that obligation begins before deployment, not after. ISO/IEC 42001 — the international standard for AI management systems — formalises this as a structured requirement: a documented management system covering risk assessment, impact evaluation, and continual improvement, applied from the point of deployment. A pre-deployment review is the entry point to that system.