4. MASO Controls¶
After this module you will be able to¶
- Describe the three MASO domains most relevant to governance: Privileged Agent Governance, Observability, and Identity & Access
- Frame MASO controls as governance obligations, not technical specifications
- Map MASO controls to existing governance frameworks (NIST AI RMF, ISO 42001, EU AI Act)
- Determine which MASO controls your governance framework should require based on risk tier
MASO through the governance lens¶
The MASO framework (Multi-Agent Security Operations) defines controls across eight domains for multi-agent systems. If you are a security architect, you need to understand all eight domains and how they integrate technically. If you are a governance professional, you need to understand three things:
- Which domains carry governance obligations, where "obligation" means a control whose absence creates regulatory, fiduciary, or accountability risk
- How these domains extend your existing frameworks, specifically what they add that NIST, ISO 42001, and the EU AI Act do not already cover
- What evidence standard the controls require, meaning how you demonstrate to a regulator that the controls are adequate
This module focuses on the three domains with the strongest governance implications: Privileged Agent Governance, Observability, and Identity & Access. It also covers Objective Intent, which provides the formal reference standard for behavioural assurance. The remaining four domains (Epistemic Integrity, Data Protection, Execution Control, Supply Chain) are governance-relevant but are more directly operational. We will reference them where they intersect with governance obligations.
The eight MASO domains: governance summary¶
Before diving into the priority domains, here is a governance-level view of all eight:
| Domain | Governance relevance | Key governance question |
|---|---|---|
| 1. Prompt, Goal & Epistemic Integrity | HIGH: directly addresses the reasoning-basis gap (Module 3) | Do agents verify the completeness of their decision inputs? |
| 2. Identity & Access | HIGH: defines who or what can invoke consequential agents | Which agents are authorised to make or support consequential decisions? |
| 3. Data Protection | MEDIUM: extends existing data governance to agent boundaries | Is sensitive data protected as it flows between agents? |
| 4. Execution Control | MEDIUM: defines runtime boundaries and circuit breakers | Can the system stop itself when integrity degrades? |
| 5. Observability | HIGH: determines whether you can demonstrate governance | Can you prove to a regulator that the chain operated correctly? |
| 6. Supply Chain | MEDIUM: extends third-party risk to agent components | Do you know what models and tools your agents are using? |
| 7. Privileged Agent Governance | HIGH: addresses the accountability gap for agents with elevated authority | Who oversees agents that can approve, execute, or commit? |
| 8. Objective Intent | HIGH: provides the formal reference standard for behavioural assurance | Can you demonstrate that agents did what the developer designed them to do? |
Domain 7: Privileged Agent Governance¶
Why this domain matters for governance¶
In the Phantom Compliance scenario, Agent C had the authority to approve a trade. That is a privileged action: it commits the firm to a financial transaction with regulatory implications. In a human process, the person who approves a trade is subject to specific governance requirements: training, authorisation, supervision, and audit. Agent C had none of these.
Privileged Agent Governance is the MASO domain that addresses this gap. It applies elevated oversight requirements to agents that perform actions with significant consequences, actions that, if performed by a human, would require specific authorisation and oversight.
Key controls for governance professionals¶
PAG-01: Privileged agent identification. Every agent in the chain that performs a consequential action must be identified and classified. "Consequential" means an action that creates a commitment (financial, legal, clinical, operational) or that downstream agents or humans will treat as authoritative.
Governance obligation: Maintain a register of privileged agents, analogous to the register of authorised signatories or trading authorities that financial firms already maintain.
PAG-02: Delegation authority. When a privileged agent relies on another agent's output to make its decision, the delegation must be explicitly authorised and bounded. Agent C's reliance on Agent B's compliance assessment is a delegation, and it must be governed as one.
Governance obligation: Define and document which inter-agent delegations are authorised, what quality standards the delegated output must meet, and who is accountable for the delegation relationship.
PAG-03: Override and escalation. Privileged agents must have defined conditions under which their authority is suspended and the decision escalates to a human. These conditions must include epistemic integrity failures; if the reasoning basis is incomplete, the agent must not exercise its privilege.
Governance obligation: Define escalation criteria for each privileged agent. Review escalation criteria regularly (at least annually and after any incident).
If Meridian Capital had implemented Privileged Agent Governance:
- Agent C would have been identified as a privileged agent (it approves trades)
- Its reliance on Agent B would have been documented as an authorised delegation, with quality standards for Agent B's output (including completeness requirements)
- Agent C would have had an escalation trigger: if Agent B's output lacked completeness metadata, or if completeness fell below a threshold, Agent C would escalate rather than approve
The trade would not have been automatically approved.
Domain 5: Observability¶
Why this domain matters for governance¶
Module 1 established that Phantom Compliance had a perfect audit trail (every agent logged its inputs and outputs) and yet the failure was invisible. The problem was not the absence of logging. It was the absence of the right kind of observability.
Observability in MASO is not "we log everything." It is "we can demonstrate, after the fact and in real time, that the reasoning chain operated with integrity."
For governance, this is the difference between compliance theatre (we have logs) and operational assurance (we can prove it worked).
Key controls for governance professionals¶
OBS-01: Chain-level tracing. Every execution of a multi-agent chain must produce a trace that connects inputs, inter-agent handoffs, and outputs in a single auditable record. Per-agent logs are necessary but not sufficient.
Governance obligation: Require chain-level tracing for all multi-agent systems. Define retention periods aligned with regulatory requirements. Ensure traces are tamper-evident.
OBS-02: Reasoning-basis logging. For every consequential agent action, the observability layer must capture not just the output but the data the agent actually accessed. This includes retrieval results, tool call responses, context window utilisation, and completeness metrics.
Governance obligation: Define what reasoning-basis metadata must be captured for each agent in the chain. This is the governance equivalent of requiring a compliance officer to document not just their conclusion but the sources they consulted.
OBS-03: Integrity metrics. The observability layer must provide real-time and historical metrics on chain integrity: retrieval completeness ratios, cross-agent consistency scores, confidence calibration, and escalation rates.
Governance obligation: Define integrity metrics and thresholds for each multi-agent system. Include these metrics in regular governance reporting. Define alert conditions for threshold breaches.
OBS-04: Audit readiness. The observability data must be structured and accessible for audit. An auditor should be able to select any chain execution, trace it from input to output, and verify the reasoning basis at each step, without requiring engineering support.
Governance obligation: Include observability audit readiness in your AI system audit criteria. Test it: ask your auditors to trace a sample chain execution. If they cannot do it without engineering help, the control is not adequate.
The governance test for observability: Can you demonstrate to a regulator, within a reasonable timeframe and without engineering support, that a specific chain execution was based on complete and current data? If the answer is no, your observability controls are not governance-adequate, regardless of how much data you log.
Domain 2: Identity & Access¶
Why this domain matters for governance¶
In traditional systems, identity and access management (IAM) controls who can do what. For multi-agent systems, IAM must also control which agents can invoke which other agents, with what authority, and under what conditions.
In Phantom Compliance, Agent C accepted Agent B's compliance assessment without any verification of whether Agent B was authorised to make that assessment, whether Agent B had access to the full data it needed, or whether Agent B's output met quality standards. There was no inter-agent access control; any agent in the chain could invoke any other agent and accept its output unconditionally.
Key controls for governance professionals¶
IAM-01: Agent identity. Every agent in a multi-agent chain must have a verifiable identity, not just a name in a log but a cryptographically verifiable identity that can be audited. This prevents agent substitution (replacing a capable agent with a less capable one) and enables accountability tracing.
Governance obligation: Maintain an agent identity registry. Ensure that agent identities are verifiable and that identity changes are logged and reviewed.
IAM-02: Scoped permissions. Each agent must have defined permissions that limit what it can do and what data it can access. Agent B should have explicit permission to access the restricted securities list, and the access control system should be able to verify that the access was complete, not partial.
Governance obligation: Define permission scopes for all agents in consequential chains. Review permissions regularly (at least annually). Ensure that permission scope changes follow a change management process.
IAM-03: Inter-agent authorisation. When one agent invokes another agent, the invocation must be authorised. Agent C's acceptance of Agent B's output is an implicit authorisation. Making it explicit means defining what output from Agent B Agent C is authorised to accept, and under what conditions.
Governance obligation: Map inter-agent authorisation relationships for all multi-agent systems. Document the trust assumptions embedded in each relationship. Review whether those trust assumptions are warranted.
IAM-04: Least privilege for agents. Agents should have the minimum permissions necessary for their task. An agent that only needs to check a restricted securities list should not have access to all compliance databases. This limits the blast radius of any single agent failure.
Governance obligation: Apply the principle of least privilege to agent permissions, as you would for human system users. Audit for permission creep.
Domain 8: Objective Intent¶
Why this domain matters for governance¶
The three domains above address specific governance gaps: who has authority, whether you can prove integrity, and who can invoke whom. But none of them answer the fundamental question: is the system doing what the developer designed it to do?
Objective Intent is the MASO domain that closes this gap. It requires every agent, judge, and workflow to have a declared Objective Intent Specification (OISpec): a structured, versioned document that states what the component is supposed to achieve, within what parameters, and against what success and failure criteria.
Key controls for governance professionals¶
OI-01: OISpec declaration. Every agent and workflow must have a declared Objective Intent Specification, authored by the developer at design time. The OISpec is not internal documentation. It is a machine-readable contract consumed by judges, evaluation agents, and the observability layer.
Governance obligation: Require OISpec declarations for all agents in consequential multi-agent systems. Treat OISpecs as governance artefacts subject to review, versioning, and audit, comparable to how financial firms manage trading algorithms.
OI-02: Strategic evaluation. A workflow-level evaluator must assess whether all agents collectively achieved the workflow's declared intent. This is not the same as verifying that each agent passed its individual checks. It is the evaluation that catches "every agent did its job, but the result is wrong."
Governance obligation: Require strategic evaluation for all multi-agent workflows at Tier 2 and above. Define what constitutes an emergent failure (individually compliant agents producing a collectively wrong outcome) and require monitoring for it.
OI-03: Judge intent monitoring. Judges themselves must have declared OISpecs, and their behaviour must be monitored against those specifications by an independent evaluator. A judge without declared evaluation criteria is a black box with authority.
Governance obligation: Require OISpecs for all judges and evaluation agents. Include judge intent compliance in governance reporting. Define escalation paths for judge drift.
If Meridian Capital had implemented Objective Intent:
- Agent B would have had a declared OISpec stating its goal ("verify trade compliance against restricted securities list"), its success criteria ("all restricted securities are checked"), and its failure criteria ("compliance assessment issued without full retrieval")
- A tactical judge would have evaluated Agent B's output against its OISpec and detected that the success criteria were not met
- A strategic evaluator would have assessed whether the workflow's aggregate intent ("produce a verified compliance assessment for the trade") was satisfied, catching the gap even if the tactical check was missed
- The trade would not have been approved because the system could evaluate not just whether something went wrong mechanically, but whether the declared purpose was actually achieved
For the full OISpec schema, tiered controls, and evaluation architecture, see Objective Intent.
Mapping MASO to existing frameworks¶
One of the strengths of MASO is that it extends rather than replaces existing governance frameworks. Here is how the governance-relevant MASO domains map to the frameworks discussed in Module 2:
MASO + NIST AI RMF¶
| NIST AI RMF function | MASO extension |
|---|---|
| GOVERN: Establish AI governance structures | Add privileged agent identification and inter-agent delegation authority to governance scope |
| MAP: Identify and characterise AI risks | Add chain-level risks, inter-agent trust assumptions, and reasoning-basis completeness to risk identification |
| MEASURE: Evaluate AI systems | Add chain integrity metrics, epistemic integrity verification, and observability audit readiness to evaluation criteria |
| MANAGE: Manage AI risks | Add chain-level circuit breakers, privileged agent escalation, and runtime integrity monitoring to risk management |
MASO + ISO 42001¶
| ISO 42001 clause | MASO extension |
|---|---|
| 4.3 Scope: Define AIMS scope | Include multi-agent chains as governance objects, not just individual AI systems |
| 6.1 Risk assessment: Identify and assess risks | Add chain-level risk categories: reasoning-basis corruption, confidence laundering, emergent delegation behaviour |
| 8.1 Operational planning: Plan AI operations | Include inter-agent integrity verification, privileged agent oversight, and chain-level observability in operational plans |
| 9.2 Internal audit: Audit the AIMS | Add chain-level audit criteria: can auditors trace chain executions, verify reasoning basis, and assess inter-agent trust? |
| Annex A controls: Control catalogue | Extend Annex A with MASO controls for inter-agent integrity, privileged agent governance, and chain-level observability |
MASO + EU AI Act¶
| EU AI Act requirement | MASO extension |
|---|---|
| Article 9: Risk management | Include chain-level risks in the risk management system. MASO provides the risk taxonomy for multi-agent systems |
| Article 10: Data governance | Extend data governance to runtime data flows between agents, not just training data |
| Article 12: Record-keeping | Extend record-keeping to chain-level traces with reasoning-basis metadata, not just per-system logs |
| Article 13: Transparency | Extend transparency to inter-agent trust relationships and delegation authorities |
| Article 14: Human oversight | Extend human oversight requirements to include access to chain-level integrity data and reasoning-basis metadata |
The extension principle: MASO is not a replacement for existing frameworks. It is the multi-agent extension layer. For every requirement in your existing framework, MASO asks: "Does this requirement cover what happens when agents delegate to agents?" Where the answer is no, MASO provides the specific controls to close the gap.
MASO by risk tier: governance implications¶
The AIRS framework defines three risk tiers that determine the intensity of MASO controls. For governance, the tier determines the oversight obligation:
Tier 1: Supervised¶
Human-in-the-loop for all consequential decisions.
Governance implication: The governance framework must ensure that human reviewers have access to chain-level integrity data, not just agent outputs. A human who reviews only Agent C's output will approve the same trade the system approved.
Minimum MASO controls: Privileged agent identification, basic chain-level logging, human review of all chain outputs.
Tier 2: Managed¶
Automated controls with human oversight for flagged cases.
Governance implication: The governance framework must define the automated controls, the flagging criteria, and the escalation paths. It must also define how the effectiveness of these controls is measured and reported.
Minimum MASO controls: All Tier 1 controls plus automated epistemic integrity verification, chain-level integrity metrics with alerting, inter-agent authorisation, and regular control effectiveness testing.
Tier 3: Autonomous¶
Full automation with controls at every layer.
Governance implication: The governance framework must demonstrate that automated controls are equivalent to or better than human oversight for the specific risk context. This requires comprehensive evidence of control effectiveness, not just deployment.
Minimum MASO controls: All Tier 2 controls plus real-time chain integrity monitoring, automated circuit breakers with PACE fallback, full reasoning-basis verification at every inter-agent boundary, and continuous control effectiveness measurement.
What to require as a governance professional¶
You do not need to implement MASO controls. You need to require them, set adequacy standards, and verify compliance. Here is a practical checklist:
Immediate actions:
- Identify all multi-agent AI systems in your organisation
- For each system, identify privileged agents (agents that make or support consequential decisions)
- Determine the appropriate risk tier for each system
- Assess whether current governance frameworks cover chain-level risks
Framework extension actions:
- Add multi-agent chains to the scope of your AI governance framework
- Define inter-agent delegation as a governance-controlled activity
- Require chain-level observability (not just per-agent logging)
- Add epistemic integrity to your AI system adequacy criteria
Ongoing governance actions:
- Include chain integrity metrics in regular governance reporting
- Require periodic control effectiveness testing (not just deployment verification)
- Audit inter-agent trust relationships at least annually
- Review privileged agent registers and escalation criteria after any incident
Reflection
Take one multi-agent AI system in your organisation (or one you are evaluating). Apply the three priority MASO domains:
- Privileged Agent Governance: Which agents perform consequential actions? Are their delegations documented and bounded?
- Observability: Can you trace a chain execution from input to output, including reasoning-basis metadata? Can an auditor do this without engineering support?
- Identity & Access: Are inter-agent invocations authorised and scoped? Could an agent accept output from an unauthorised or substituted upstream agent?
Consider
If you find that you cannot answer these questions for your multi-agent systems, that is itself a governance finding. The inability to assess chain-level governance indicates that the governance framework does not yet cover multi-agent systems, which is the gap this entire track has been describing.