Operational sovereignty: deciding what AI is allowed to do on your behalf

What does operational sovereignty cover?

Data, infrastructure and model sovereignty decide what AI runs on and with. Operational sovereignty decides what AI *does*. It covers four things named in the brief: agents, workflows, decisions and actions. You decide what AI is allowed to do on your behalf, and under what limits.

This matters more as AI moves from answering to acting. A chatbot that gives a wrong answer wastes someone's time. An agent that sends the email, changes the record or places the order creates an event in the real world. The question stops being whether the model is good and becomes whether the organisation can say, in advance and in writing, what this agent may do. That is the territory of Governed Agents and Governed Workflows, layers 04 and 05 of the platform.

How should authority be delegated to an AI agent?

Treat an agent like a new employee with a very specific job and no history. It gets an identity, an owner, a defined scope and supervision. Authority is delegated by a named person, for a named purpose, and it can be withdrawn.

• Identity. Every agent acts as a known identity, not as a shared service account. Without identity there is no accountability.
• Owner. A named person or team is accountable for the agent's behaviour, cost and retirement.
• Purpose. A written description of the job. Anything outside it is out of scope by default.
• On whose behalf. Decide whether the agent acts with the user's permissions, its own narrower ones, or both. The narrower set should win when they conflict.
• Expiry. Delegations are reviewed and renewed, not granted forever.

These facts live in the agent's Trust Profile: identity, owner, risk level, approved models, data classification, data residency, permitted systems, allowed actions, restricted actions, human approval rule, retention, audit and policy set. The profile is the delegation, written down in a form the platform can enforce.

What does least privilege mean for tools and data?

An agent's power is the union of its tools. Every connected system multiplies what a prompt injection, a bad instruction or a plain mistake can do. Least privilege means giving the agent the narrowest access that lets it do the job, at the finest grain the target system allows.

• Read before write. Start with read-only access. Add write actions one at a time, each with its own approval rule.
• Scope by action, not by system. Permission to create a draft purchase order is not permission to approve one.
• Scope by data. The agent reads the approved supplier records, not the whole finance database.
• Short-lived credentials. Issue credentials per task where possible, and keep them out of prompts and logs.
• Constrain the tool layer. Tools exposed through open protocols such as MCP, which Anthropic donated to the Linux Foundation's Agentic AI Foundation in December 2025 (opens in a new tab), still need the same permission checks. A standard interface does not make a tool safe. See the MCP interoperability post.

How do autonomy levels turn trust into something you can grant gradually?

Autonomy is not a switch between manual and autonomous. The platform uses five levels of controlled autonomy, and each is granted per agent, per action, on evidence.

Moving up a level changes four things: the approval rule, the monitoring, the risk boundaries and the depth of audit. It is a decision made by the accountable owner and recorded in the Trust Profile, never by the agent itself. Many agents should stay at L2 or L3 permanently. See controlled autonomy for what each level looks like, and the practical rollout plan.

What does this look like for a real agent?

Here is the worked example used across the platform: an AI Procurement Agent. Its Trust Profile splits its authority into what it can do, what it cannot, what needs a person, and what is recorded.

Notice the shape. The agent can do real work, preparing and drafting, and cannot do the three things that carry irreversible financial or legal consequence. Every action leaves a record, so a reviewer can reconstruct what happened. That is operational sovereignty in one page: delegated, bounded, supervised and evidenced.

Where do approval gates belong?

Approval gates are where a human stays in charge. Put them where the cost of a wrong action is high or the action is hard to reverse, and keep them out of the rest, or reviewers will approve everything without reading.

• Threshold gates. Amounts, record counts, recipient counts above a limit.
• Category gates. Contract changes, external communications, access changes, anything touching people decisions.
• Novelty gates. First time an agent touches a new system or a new type of record.
• Confidence or anomaly gates. The agent or a monitor flags that something looks unusual.

A gate needs a named approver, a time limit and a defined outcome if nobody answers. Default to not proceeding. Measure approval and edit rates: a gate that is always approved without change is a candidate for relaxing, and a gate that is often edited tells you the agent needs work. Under the EU AI Act, human oversight is a requirement for high-risk systems, covered in governance sovereignty.

What are the kill switch, rollback and incident response for agents?

Plan for the day an agent does something wrong. Agents fail in ways that differ from ordinary software: they act at machine speed, and they can fail by doing a plausible wrong thing rather than crashing.

1. A kill switch per agent and one for everything. Revoking an agent's credentials and pausing its workflows must take seconds and must not depend on the agent cooperating.
2. Safe states. Define what happens to in-flight work when an agent is stopped: complete, queue or roll back.
3. Rollback and compensation. For each write action, know how to undo it. Where you cannot, that action needs a gate.
4. An incident runbook. Who is paged, who decides to stop, who communicates, how evidence is preserved, how the affected records are found.
5. Reconstruction from the record. The audit trail must let you trace the incident from data to model to agent to decision to action to outcome. See runtime governance.
6. Post-incident change. Tighten the Trust Profile, add a test to the evaluation set, and drop the autonomy level until the fix is proven.

Observability is the precondition. You cannot stop what you cannot see. The OpenTelemetry project is defining conventions for agent spans such as invoke_agent and execute_tool, though they are still at Development status and not stable, per the OpenTelemetry GenAI agent spans documentation (opens in a new tab). Design your telemetry so field names can change without losing history. More on this in agent observability.

Who is accountable, and what belongs in a runbook?

Accountability cannot be delegated to software. For each agent and workflow, a human owner is accountable for outcomes, a technical owner for operation, and a risk or compliance contact for policy. Record all three. When a regulator, an auditor or a customer asks who was responsible, the answer should be a name.

• Purpose and scope of the agent, and its autonomy level.
• Permitted systems and actions, copied from the Trust Profile.
• Approval rules and approvers, including who covers when they are away.
• Monitoring signals and alert thresholds.
• Stop procedure and the safe state.
• Escalation path and communication templates.
• Review date for the delegation and the autonomy level.

On the Sovereign Intelligence Platform, these runtime controls sit in Governed Agents and Governed Workflows. Nexus captures every agent action, enforces policy in-flight and traces every agent and connection, and Studio is where agents and automations are built. Where a control is designed for rather than generally available, the trust centre is the place to check current status. The step-by-step guide covers building these in order.