The L0–L8 architecture map

The layers are decision boundaries, not a mandatory product stack. One component may implement several layers, and one layer may span several services. What matters is that responsibility, authority, evidence and failure behavior remain explicit across their interfaces.

The control flow across the map

A governed system moves through a chain of commitments: purpose → admission → orchestration → context → capability → authorization → evaluation → effect. Evidence travels back in the opposite direction. An observed effect informs evaluation; evaluation informs promotion or rollback; those decisions inform portfolio and risk owners. A missing receipt, uncertain source or unavailable policy service must not be converted into a clean outcome.

End-to-end example: prepare an access review

The same bounded example used in the three introductory guides is expanded here so that architecture, security and GRC describe one system rather than three disconnected stories.

  1. L0–L1

    Bound the decision

    The objective is to prepare a quarterly access review, not to prove compliance or autonomously remove accounts. The application owner accepts the use case, scope and success criteria.

  2. L2

    Qualify the workflow

    A versioned workflow, test set and rollback path are approved for a named environment. A prompt edit or connector change cannot silently become the production version.

  3. L3–L4

    Collect governed evidence

    The runtime retrieves the in-scope roster, approved roles and prior exceptions. Each item retains source, collection time, tenant, applicability and freshness; missing data becomes an exception.

  4. L5–L6

    Authorize each capability

    Read-only connectors are matched to admitted capability records. The enforcement point checks principal, agent, tenant, purpose, resource and operation. A cross-tenant identifier is denied even when it is syntactically valid.

  5. L7

    Evaluate the result

    The review compares every in-scope account with an owner or explicit exception, records unsupported conclusions and routes unresolved cases to an accountable reviewer.

  6. L8

    Verify the effect

    If remediation is later authorized, execution uses a separate bounded path. Closure requires observation from the identity system; a generated report or successful tool response is not proof that access changed.

Four interfaces that commonly fail

  • L1 → L2: business sponsorship is mistaken for technical qualification or deployment approval.
  • L4 → L5: retrieved content or a tool description is treated as authority instead of untrusted input.
  • L5 → L6: a discoverable, schema-valid tool call bypasses resource-side authorization.
  • L7 → L8: a success response or completed task is treated as proof of the intended resource-side effect.

Choose the next guide by question

Architecture primer

What is an AI agent harness?

Use this when you need the components, system boundary and first bounded workflow.

Read the architecture guide ↗
Security primer

How are actions constrained?

Use this for prompt injection, permissions, tenant boundaries, approvals and negative tests.

Read the security guide ↗
GRC primer

How are controls and evidence assessed?

Use this for evidence collection, human review, auditability and assurance boundaries.

Read the GRC guide ↗

Primary references and limits

  • NIST AI Risk Management Framework informs governance, measurement and lifecycle risk management; it does not prescribe this L0–L8 map.
  • NIST SP 800-207 informs contextual, least-privilege access decisions; it does not certify an agent workflow.
  • MCP tools specification defines discovery and invocation contracts; tool visibility is not business authorization.
  • OWASP LLM06 Excessive Agency supports limiting functionality, permissions and autonomy; the layer model and example are this author's architecture synthesis.

This overview does not claim a deployed or certified platform, prove control effectiveness, or replace legal, security or audit judgement. Its purpose is to make responsibilities and evidence paths testable before implementation choices obscure them.

Privacy Notice: With your consent, this website uses Google Analytics to understand aggregate visits and content usage. Analytics is optional and is not used for advertising or cross-site profiling. Some content and images may be generated or modified with the assistance of AI; every AI-assisted item is reviewed and manually edited by a human before publication. Full Privacy Policy · AI modified — reviewed and edited by a human