What we build to, and what we claim.
We hold no certifications. We build against public standards, state our coverage, and publish the evidence so you can check it rather than take our word for it.
The frameworks
OWASP — GenAI Security Project
- Covers
- The named risks in LLM and agent applications — prompt injection, data leakage, excessive agency, retrieval weaknesses, runaway consumption.
- We claim
- Every system we build is designed against the current Top 10 for LLM Applications and, where agents are involved, the Top 10 for Agentic Applications. Coverage is stated per item in the matrix below.
Source: genai.owasp.org
NIST SSDF — SP 800-218
- Covers
- How software gets built securely, across four practice groups: prepare the organisation, protect the software, produce well-secured software, respond to vulnerabilities.
- We claim
- Our engineering standard is structured against these practices. Threat modelling at scoping, review before merge, dependency and secret scanning, signed releases, and a published disclosure route.
Source: csrc.nist.gov
NIST SP 800-218A
- Covers
- The generative AI profile of the SSDF — training data governance, model supply chain, evaluation of model behaviour.
- We claim
- Applied where an engagement involves fine-tuning or client-controlled training data. Where a system is built on hosted model APIs, we say which practices apply and which sit with the provider.
Source: csrc.nist.gov
SLSA — Build Level 3
- Covers
- Supply-chain integrity — whether a released artifact can be traced, verifiably, to the source and pipeline that produced it.
- We claim
- Build Level 3. Our provenance can be verified against the specification with standard tooling. See below.
Source: slsa.dev
NIST AI RMF
- Covers
- Managing AI risk across a system's life — govern, map, measure, manage.
- We claim
- Used as the structure for per-project AI risk records: intended purpose, data sources, known limitations, accuracy metrics, human oversight requirements and monitoring.
Source: nist.gov
CIS Benchmarks
- Covers
- Hardening configurations for cloud platforms and workloads.
- We claim
- Cloud environments are configured against the applicable benchmarks — least privilege, private networking by default, encryption in transit and at rest, audit logging retained and protected.
Source: cisecurity.org
Coverage matrix
The OWASP risks in our own words, with the control we apply and its status.
| Risk | Status | Note |
|---|---|---|
| Hidden instructions in content the system reads | Implemented | Instructions and content kept structurally separate. Retrieved content is treated as data, never as command. Tool calls validated against an explicit schema and permission set before execution. |
| Sensitive data appearing in output or logs | Implemented | Secrets never enter prompts or model context. Inputs and outputs filtered. Logs scrubbed before they are written. |
| Compromised models, datasets or packages | Implemented | Models obtained from verified sources. Serialised model files from untrusted origins are never loaded. Dependency inventory on every release, covering model components as well as packages. |
| Corrupted training or retrieval data | Scoped | Where an engagement involves fine-tuning or client-controlled training data, provenance and integrity are established before use and behaviour is evaluated before and after. Where a system runs on hosted model APIs without fine-tuning, this sits with the provider. |
| Model output used unsafely downstream | Implemented | Output treated as untrusted input everywhere. Never passed into code execution, queries, shell commands or rendered markup without validation and escaping. |
| Agents able to do more than the task requires | Implemented | Narrowest capability that accomplishes the task. Each agent has its own identity and credentials. Tool access explicitly enumerated. Irreversible, costly or externally visible actions gated behind human confirmation. |
| System prompt extracted | Implemented | Nothing secret lives in a system prompt. No security property depends on a prompt staying hidden. |
| Retrieval reaching data the user should not see | Implemented | Access control enforced at retrieval time. Tenant isolation in the vector store. Ingestion sources controlled. |
| Confident wrong answers | Implemented | Answers grounded in retrieved sources with citation back where feasible. Evaluated against a task-specific test set before release, and the evaluation delivered to you. |
| Runaway cost and consumption | Implemented | Rate limits, token ceilings, loop bounds and spend alerts configured before production. |
For agent systems, additionally
| Risk | Status | Note |
|---|---|---|
| Poisoned agent memory | Implemented | Persisted state treated as untrusted on read. |
| Agents trusting each other blindly | Implemented | Output from one agent validated before another acts on it. |
“Scoped” means the risk applies only to certain engagements, and we say which case yours is during scoping.
Build provenance
You do not have to take our word for what is in a release.
Our pipelines meet SLSA Build Level 3. The build platform is hardened, builds are isolated from one another, and signing material is not reachable from any build step the code itself can influence — provenance is generated by an isolated workflow the calling build cannot alter, with keyless signing.
Every artifact we ship carries a signed record of what source it was built from, by which pipeline, and when. Every release carries a software bill of materials listing every dependency it contains.
$ slsa-verifier verify-artifact modulariti-api-1.4.2.tar.gz \
--provenance-path provenance.intoto.jsonl \
--source-uri github.com/modulariti/api
Verified signature against tlog entry index 84512309
Verified build using builder "slsa-github-generator@v2.1.0"
PASSED: SLSA verification passedRun it yourself against anything we deliver.
Where our claims come from
None. We hold no audited certification against any standard on this page.
Our engineering standard, and the coverage stated in the matrix above. Written down, versioned, and public — but assessed internally, not audited.
Build provenance, dependency inventories, signed artifacts, and the evaluation results delivered with each system. These need no trust in us at all. Check them with your own tooling.
Disclaimer
Where audited assurance is required, we will identify that during scoping and work with you or an independent assessor to address it.