L6 · MAESTRO
Security and Compliance
Not a peer layer but a vertical band cutting across all the others: the security policy, who is accountable for it, and how compliance is verified.
L6 is cross-cutting: security and compliance policy wraps every component above, not a single box on the architecture.
The Security and Compliance layer is not a peer of the other six layers. It is a vertical band that cuts across all of them. Where L1 through L5 and L7 describe what architectural components exist and where threats land, L6 asks a different question: across the entire system, what is the security policy, who is accountable for enforcing it, and how is compliance verified? Every other layer has a security and compliance concern that lives in L6. Model governance is an L6 concern applied to L1 artifacts. Data classification policy is an L6 concern applied to L2 stores. Autonomy boundaries are an L6 concern applied to L3 orchestration. Identity and access management is an L6 concern applied to L4 infrastructure. Audit log retention mandates are an L6 concerns applied to L5 tooling. Third-party ecosystem vetting is an L6 concern applied to L7 integrations.
The MAESTRO guide (Cloud Security Alliance, Ken Huang, 2025) represents L6 as a vertical band in its architecture diagram specifically to communicate this cross-cutting character. Helmwart reproduces this in the MAESTRO stack SVG on the Frameworks page.
Concrete example: A healthcare provider deploys a LangChain-based clinical-summarisation agent. HIPAA requires an audit trail for every access to patient records, but the team never defined an L6 audit-log retention policy, so the L5 logging infrastructure captures spans but auto-rotates them after seven days. When a data-access complaint surfaces six weeks later, the records are gone. The L5 mechanism existed; the L6 mandate and retention schedule did not. No amount of technical sophistication at L1–L5 compensates for an absent governance layer.
What lives here
- Identity and access management policy: who (human or machine) may invoke which agents, tools, or data stores, under what conditions
- Non-human identity (NHI) governance: service account lifecycle, credential rotation policy, workload identity standards
- Autonomy boundary policy: the declared maximum autonomous action radius for each agent class before human review is required
- Data governance: classification schema, retention schedules, DLP rules, regulated-data handling procedures
- Compliance mandates applicable to the deployment: EU AI Act transparency obligations, HIPAA audit requirements, FedRAMP logging rules, SOC 2 change-management controls
- Third-party due diligence: vetting process for MCP servers, external tool providers, peer-agent operators, and model suppliers
- Incident response policy: what events trigger containment, who has stop-build authority, how evidence is preserved
- Red team and audit program: schedule, scope, and accountability for adversarial evaluation of the system
- Human-in-the-loop governance: which action classes require human approval, what constitutes informed consent, how reviewer decisions are recorded
Threats that target this layer
- T3 Privilege Compromise: the policy gap that allows privilege compromise to persist is an L6 failure: insufficient access review, absent least-privilege policy, or a NHI lifecycle program that allows stale credentials to accumulate.
- T7 Misaligned and Deceptive Behaviors: emergent agent behaviours that violate organisational or regulatory policy land at L6 when the root cause is insufficient governance: no declared autonomy boundary, no behavioural testing program, no stop-build authority exercised when misalignment was observed.
- T8 Repudiation and Untraceability: the audit log retention policy, tamper-evidence requirement, and access controls on log data are L6 policies. T8 succeeds when those policies are absent or unenforced.
- T10 Overwhelming Human-in-the-Loop: the design of the HITL program (which decisions require human approval, what reviewer capacity is maintained, what workload limits apply) is an L6 governance decision, not a framework-layer implementation detail.
Mitigations anchored here
- RBAC and ABAC: role-based and attribute-based access control policy applied consistently across all layers. L6 owns the policy definition; L4 enforces it at the infrastructure layer.
- NHI lifecycle management: governance of non-human identity lifecycle: creation approval, rotation schedule, scope review cadence, and revocation on decommission. The policy lives in L6; the implementation lives in L4.
- Open Policy Agent: Open Policy Agent (or equivalent) as the policy enforcement point for autonomy boundary decisions, tool access, and data handling rules. Centralises policy in L6 while enforcing it at L3 and L4.
- policy-bound autonomy: declare an explicit maximum autonomous action radius per agent class (e.g., read-only by default; write actions require HITL; irreversible actions require dual-control). This is a governance artifact that lives in L6 and is referenced by L3, L4, and L5 controls.
- per-agent trust scoring: maintain a continuously-updated trust score for each peer agent, MCP server, and external tool provider. Scored entities with degraded trust are automatically routed through additional validation or blocked. Trust governance is an L6 accountability.
- behavioural red-teaming: a structured red team program that tests agent behaviour against declared policy. Red team scheduling, scope, and accountability for remediation are L6 governance; execution touches every other layer.
- MFA on high-privilege identities: require multi-factor or out-of-band verification for high-privilege actions. The policy definition of what constitutes “high-privilege” is an L6 decision.
- emergency-stop control: a documented, tested, and governed procedure for suspending or terminating an agent class. The existence and exercisability of the kill switch is an L6 governance requirement; the technical mechanism lives in L4/L5.
How L6 relates to all other layers
L6 does not sit between any two layers. It spans all of them. The practical consequence is that L6 controls are often implemented at multiple other layers simultaneously:
- An identity policy (L6) is enforced by L4 IAM configuration and L3 tool-scope checks.
- A data classification policy (L6) is implemented by L2 store access controls and L5 DLP egress rules.
- An autonomy boundary (L6) is enforced by L3 plan-validation and L4 resource quotas.
- An audit mandate (L6) is satisfied by L5 logging infrastructure and L4 tamper-resistant storage.
When a L6 policy is missing, every layer it spans has a corresponding gap. When a L6 policy exists but is not implemented at the right layer, the gap is structural and usually invisible until an incident surfaces it.
L6 is the layer that asks whether the other six layers are governed: whether the controls that exist were deliberately chosen, whether the policies they enforce are documented and accountable, and whether the system as a whole meets the obligations that apply to it. Technically sophisticated deployments with immature L6 governance are common, and consistently fail compliance and incident-response tests when those come.
Threats at this layer
Every threat whose maestroLayers list includes L6. The prose above may discuss a subset; this list is the complete index.
Controls mapped to this layer
Auto-generated from the mitigation catalog: every mitigation whose maestroLayers list includes L6, sorted by maturity tier (Tier 1 production-canonical first, then Tier 2, then Tier 3 research-stage).
- Tier 1OPA authorisation(Open Policy Agent — a policy-as-code engine for every tool call an agent makes)
An agent can invoke any tool it has access to, constrained only by its own reasoning. If that reasoning is manipulated or the agent's permissions are misconfigured, it will call tools it should not. OPA addresses this by placing a policy decision point between the agent and every tool invocation: a Rego policy evaluates the agent identity, the tool, and the parameter envelope before execution proceeds, and the agent cannot reason or argue past the result.
Human reviewers make more errors as cognitive load accumulates over a shift. An adversary who floods a HITL gate, or a system that simply generates high output volume, exploits that degradation without bypassing the gate at all. Adaptive workload balancing addresses this by treating reviewer fatigue as a live routing input: each incoming review is assigned to the reviewer with the lowest current fatigue score, mandatory breaks are enforced before a reviewer's error rate climbs further, and items are held rather than assigned to any reviewer above the break threshold.
- Tier 2Admission control(Agent admission control — verify identity, capability claims, and provenance before a peer joins the system)
In a multi-agent system, peer agents are granted authority by the other agents that accept their outputs. A rogue or compromised agent that enters the system inherits that authority immediately. Agent admission control is the registration gate that evaluates a peer's identity, declared capabilities, and binary provenance against policy before granting access. A peer that cannot pass attestation is refused entry and cannot participate in the system.
- Tier 2Agent MFA(MFA for high-privilege agent identities — step-up attestation at credential issuance and action time)
An agent identity that holds broad write authority is a high-value target: compromising its credential gives an attacker persistent, authenticated access to every system that identity can reach. Multi-factor authentication addresses this by requiring a second factor at credential issuance time, so a stolen token is bounded to its issued lifetime and cannot be silently renewed. For non-human identities the second factor is workload attestation, hardware-bound key material, or certificate-backed proof rather than a phone or one-time code.
When an AI agent generates content or proposes an action, users need to know that the source is an AI before they decide to act. Without that signal, users routinely over-trust agent output. AI-source disclosure addresses this by attaching a visible label to every AI-generated item and by requiring explicit confirmation for consequential actions, restoring the critical gap between receipt and acceptance.
- Tier 2Blockchain tx guard(Blockchain transaction guard — pre-commit safety checks for every agent-initiated transaction)
A blockchain transaction, once committed, cannot be undone. An agent that signs and broadcasts a transaction without an enforcement layer before it can exceed its authorised value, call a contract it was never provisioned to reach, or drain a wallet in a runaway loop, and by then the funds are gone. A transaction guard intercepts each proposed transaction before signing, checks it against value bounds, a contract allowlist, a gas or compute-unit limit, and a replay-protection nonce, and refuses to sign anything that falls outside declared policy.
- Tier 2Cross-client isolation(Cross-client isolation — request-scope tenant boundaries in shared MCP server deployments)
A shared MCP server that accepts connections from multiple clients is a concentration point where one client's session state, credentials, and resource budget are physically co-located with every other client's. Without enforced isolation, a malicious or compromised client can read another session's cached credentials, consume shared resources to the point of denying service to other clients, or exploit aggregate server permissions that exceed its own declared scope. Cross-client isolation is the set of structural controls that close those paths: per-session state scoping, per-client permission evaluation, and per-client resource quotas enforced at the server layer.
An agent that operates across HR, Finance, cloud, and SaaS systems accumulates permissions at each boundary, often without any single team seeing the combined picture. Privilege accumulates silently across those boundaries until a quarterly review finds it, by which point a compromised or misconfigured agent has had weeks of unchecked reach. Cross-system scope auditing prevents that by continuously reconciling the agent's actual entitlements against a declared baseline across every system it touches and raising a ticket the moment drift is detected.
When an agent decision reaches a human reviewer, the reviewer must reconstruct the agent's reasoning from raw traces before they can form a judgment. OWASP T10 names this reconstruction burden as the mechanism behind reviewer fatigue and oversight failures. A decision summary addresses the problem by inserting an independent model call between the agent's output and the reviewer: that call compresses the decision, evidence chain, and risk factors into a fixed-format card, reducing the per-review cognitive load without removing the human from the decision.
- Tier 2Egress isolation(Network egress isolation — deny-by-default agent→internet, enforced at the network layer)
Content-layer inspection reads outbound payloads and decides pass, redact, or quarantine per channel — but it can only classify what it can parse as content. A direct TCP/UDP socket opened by agent-executed code, a raw DNS query, or a payload encoded into DNS subdomain labels never reaches an HTTP-shaped inspection point at all. Network egress isolation closes that gap one layer down: every agent and tool-bus process sits behind a default-deny network policy, and the only path to the internet is through an enforced proxy that mediates, allowlists, and logs each connection attempt regardless of what it contains.
An AI agent operates under a non-human identity (NHI): a service principal, a task role, or a workload credential. That identity produces a stream of access events that, for a well-scoped agent, forms a narrow and predictable behavioural baseline. Identity monitoring applies User and Entity Behaviour Analytics (UEBA) to that stream, alerting when an observed access pattern deviates statistically from the baseline. Because agent behavioural distributions are tighter than those of human users, a deviation is a higher-confidence signal, and a spoofed or stolen credential used from the wrong workload origin is exactly the anomaly the technique is built to detect.
- Tier 2JIT elevation(Time-bounded privilege elevation — temporary credentials that expire automatically)
An agent running with a permanent high-privilege identity gives an attacker, or a misconfigured agent, broad access for as long as that identity persists. Time-bounded privilege elevation addresses this by issuing a short-lived credential tied to a specific action window: the agent holds elevated access only for the duration it needs, and the issuing platform revokes that access automatically when the TTL expires. This is the just-in-time (JIT) access pattern from PAM practice, applied to non-human identities.
An agent that holds a persistent catalog of invokable tools can reach any of them at any point in its session. If its reasoning is manipulated or its identity is compromised, that persistent surface is fully available to an attacker. Just-in-time tool grants remove the standing surface: a policy broker issues a time-bound, task-scoped grant immediately before the tool is needed and revokes it automatically when the task completes or the window expires.
- Tier 2Kill switch(Kill switch: human authority to halt one agent, a class, or the entire deployment)
Agentic systems can act faster than a human can intervene through normal channels. A kill switch is the operational guarantee that a named human role can stop agent activity at any scope (single instance, class, or global) through a documented runbook, without requiring a code change or redeployment, and with every invocation written to an audit trail.
An agent loads whichever model weights are available at startup unless the runtime is told exactly which artifact to load. If a poisoned or regressed weight is published to the model store, the agent picks it up silently on the next restart. A model registry prevents that: every artifact is registered with a cryptographic checksum and an approval stage, the agent runtime loads by explicit version pin, and new versions must pass a canary evaluation before promotion to production.
A Non-Human Identity (NHI) is the service account, machine principal, or formal agent identity under which an agentic system authenticates and acts. When an NHI is provisioned with broad scope, never rotated, and has no named owner, a stolen or leaked credential gives an attacker persistent access for as long as that credential remains valid. NHI lifecycle management treats each agent identity as a first-class governance object: provision narrowly with a declared scope and owner, rotate on a short schedule using platform-native short-lived credentials, audit every authentication and rotation event, re-attest that the identity is still needed, and decommission by deletion when the agent is retired.
- Tier 2Policy bound(Policy-bound autonomy — declarative runtime enforcement of the agent's action space)
An agent's authority is normally bounded only by its own reasoning. If that reasoning is manipulated, or the agent's identity is compromised, it will attempt actions the operator never intended to permit. Policy-bound autonomy addresses this by placing a declarative enforcement point between the agent and every consequential action: a policy engine evaluates the agent identity, the target tool, and the parameter envelope before execution, and the agent cannot reason or argue past the result.
Role-Based Access Control (RBAC) assigns every agent identity a named role that sets the outer limit on what it can reach. Attribute-Based Access Control (ABAC) narrows individual decisions inside that role by evaluating contextual attributes at request time. Used together, they enforce least privilege for non-human identities: the agent can only do what its role permits, and only when the request attributes satisfy the policy.
A human-in-the-loop review system saturates not from absolute decision volume but from undifferentiated volume: every item lands at the same priority, so reviewers cannot distinguish an irreversible high-consequence action from a routine low-stakes one. A risk-prioritised queue fixes this by scoring each decision before it enters the queue and routing it to the tier that matches its risk level, concentrating human attention where the cost of an error is highest.
- Tier 2Secret scan(Secret scanning on agent-generated artefacts — detecting credentials before they escape the trust boundary)
An agent produces code, configuration files, tool-call payloads, and log records continuously and at a rate no human reviewer can match. Any of those artefacts may contain a live API key, service token, or private certificate, placed there accidentally through model context, or deliberately through prompt injection or context poisoning. Secret scanning places an inspection gate at every agent output seam: regex patterns match known token formats, entropy analysis detects arbitrary high-entropy strings, and validator calls confirm which candidates are live credentials. The CI-secret-scanning pattern is mature; the agentic specialisation is seam placement, moving the scanner from the repository gate to the agent egress point, where artefacts can be intercepted before they reach any downstream system.
- Tier 2Token TTL(Short-lived tokens — bounding the credential exploitation window for agent identities)
An agent identity backed by a long-lived bearer token grants access for as long as that token remains valid. If the token is stolen, logged, or extracted from a running process, the attacker holds working credentials for weeks or months without any further action. Short-lived tokens address this by issuing credentials with a time-to-live measured in minutes or hours, automated and renewed by the platform rather than a human. When a token expires, access ends: the attacker must win the renewal process as well, which requires compromising a harder target than the token itself.
Each tool in an agent's catalog should expose only the methods, resources, and parameter ranges its designated role requires. Over-broad tool surfaces let individually authorised primitives compose into actions no human intended to grant; narrowing the scope at design time reduces both the attack surface and the blast radius of any compromise.
- Tier 2Trust score(Per-agent trust scoring — behavioural reputation for inter-agent message acceptance)
In a multi-agent system, each agent routes decisions based on what its peers report. If a peer's behaviour becomes unreliable or adversarial, agents that keep treating it with full authority will propagate whatever errors or manipulations that peer introduces. Per-agent trust scoring addresses this by maintaining a continuously updated reputation score for every peer, derived from observed behaviour, and using that score to determine how much authority each incoming message carries.
- Tier 3Intent attestation(Intent attestation tokens — a cryptographic binding from user approval to tool execution)
An agent acts on behalf of the user, but nothing in a standard OAuth bearer token records what the user actually approved. If the agent's planning is manipulated, it can invoke tools with parameters the user never sanctioned, while presenting credentials that look valid. Intent attestation fixes this by issuing a short-lived signed token that encodes the exact action and parameter envelope the user authorised, and requiring the resource server to verify that envelope before executing the call.
- Tier 3Workflow state consistency(Workflow state consistency — distributed-state integrity checks for multi-agent workflows)
When multiple agents read and write shared workflow state concurrently, a network partition, a delayed message, or an adversarially timed race condition can produce divergent views. An agent acting on stale or conflicting state may authorise an action it would reject given correct current state. Hash-chained state snapshots, merge-point conflict detection, and optimistic concurrency control close that window.