Current status: Established reference model with a prototype reference implementation. The repository is not a production agent platform, control plane, SOC product, SIEM/SOAR replacement, or production-ready implementation.
Whitepaper version 4.0 is the current publication and is distinct from repository release v4.0.0. Zenodo is the authoritative publication record for the whitepaper; the Git tag identifies the independently versioned repository release.
F7-LAS™ is Anthony Fuller's vendor-neutral, protocol-agnostic security model for designing, reviewing, and governing agentic AI systems. It separates security responsibilities across seven layers so that generative output is not treated as authority to act.
This is independent personal work. It is not affiliated with, endorsed by, or representative of Microsoft or any other employer.
| Layer | Control concern |
|---|---|
| 1 | System Prompt — soft-policy intent and role boundaries |
| 2 | Grounding / RAG — source and epistemic constraints |
| 3 | Planner / Controller — bounded planning and delegation |
| 4 | Tools & Integrations — proposed action surface and argument contracts |
| 5 | External Policy Engine — deterministic PDP/PEP guardrails |
| 6 | Sandboxed Execution — scope and blast-radius containment |
| 7 | Monitoring & Evaluation — correlated evidence and assurance |
Software supply-chain security is a cross-cutting supplemental domain, Layer S; it is not an eighth F7-LAS layer.
- The current F7-LAS Whitepaper v4.0, published at 10.5281/zenodo.22867553, with a repository SHA-256 checksum
- The immutable historical F7-LAS whitepaper v3.0
- A draft implementation guide
- A draft catalog of 46 core Layers 1–7 controls plus five supplemental Layer S controls
- Current architecture diagrams, with explicit implementation boundaries, and engineering review material
- Canonical v1.0.0 data contracts and one synthetic, offline Python + OPA workflow
- Illustrative prompts, additional policies, validators, and runtime stubs
- Supply-chain CI, behavioral tests, evidence verification, deterministic replay, and a clean-user acceptance gate for the canonical path
- Machine-readable control-to-evidence traceability covering all 51 catalog controls
The canonical workflow provides one deliberately constrained executable Layers 1–7 path. It does not make the other examples executable or production-ready. The behavioral scenario matrix exercises the canonical enforcement path; the separate golden-dataset runner validates scenario structure and does not prove the described allow/deny behavior. Non-canonical examples remain illustrative unless they are explicitly reclassified and tested.
| Repository area | Current classification |
|---|---|
| Validation scripts | Executable structural validation |
| Canonical Python + OPA path | Executable for one synthetic, offline, read-only action |
| Other OPA/PDP/PEP code | Partial prototype |
| Planner, tools, sandbox, telemetry | Illustrative prototypes |
| Other policy-engine examples | Illustrative, non-canonical patterns |
| Other end-to-end workflows | Not provided |
| Production integrations or actions | Not provided |
Nothing in this repository should be connected to production data, identities, cloud resources, security platforms, or remediation systems without independent engineering and security review.
The canonical code supports Python 3.10 or later. To reproduce the CI dependency environment, use Python 3.12.14 in an isolated environment and install the hash-locked file:
python -m venv .venv
source .venv/bin/activate
python -m pip install --require-hashes -r requirements-ci.lock
python scripts/validate-supply-chain.py
python scripts/validate-documentation.py
python scripts/validate-citation.py
python scripts/validate-control-traceability.py
python scripts/validate-prompts.py
python scripts/validate-policies.py
python scripts/allowlist-validator.py
python scripts/validate-settings.py config/settings.yaml
python scripts/validate-contracts.py
opa check --strict config/policies/canonical-workflow.rego
python -m pytest -qThese commands validate the current prototype and repository structure. They are not evidence of production readiness or full behavioral enforcement.
- Documentation index
- Current Whitepaper v4.0
- Whitepaper v4.0 permanent DOI
- Whitepaper v4.0 SHA-256 checksum
- Historical Whitepaper v3.0 artifact record
- Implementation guide
- Control catalog v0.1
- Engineering review checklist
- Current QA and maturity statement
- Canonical data contracts v1.0.0
- Canonical offline workflow
- Supply-chain and CI controls
- Clean-user acceptance
- Architecture diagrams
- Control-to-evidence traceability
- v4.0.0 release notes
- Release and exact-tag SBOM procedure
- Roadmap
- Security policy
Versions belong to individual artifacts:
| Artifact | Current version/status |
|---|---|
| Seven-layer model | Established design baseline |
| Whitepaper | v4.0, current publication; v3.0 preserved as an immutable historical artifact |
| Implementation guide | Draft; bundled with 4.0.0 but not independently versioned |
| Control catalog | v0.1 draft |
| Executable reference implementation | Prototype included in repository release v4.0.0 |
| Repository release | v4.0.0, independently versioned from Whitepaper v4.0 |
Repository version numbers do not silently change the whitepaper, control catalog, or schema versions.
- Documentation, diagrams, the model, and other authored content are licensed under CC BY 4.0.
- Executable source code and policy/configuration examples are licensed under the MIT License.
- LICENSE.md defines the file-level boundary for mixed directories.
- F7-LAS™ is a trademark of Anthony L. Fuller. Copyright licenses do not grant trademark rights or imply endorsement.
Preferred citation metadata is in CITATION.cff. The current Whitepaper v4.0 DOI is 10.5281/zenodo.22867553. Historical Whitepaper v3.0 remains preserved unchanged in the repository.
Read CONTRIBUTING.md before proposing a change. Changes to the fundamental seven-layer model require explicit author approval and must not be inferred from implementation work.