Security and Compliance

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.