Compliance

Sill’s compliance posture is framework mappings, not certifications. Sill publishes a control-by-control mapping that shows where named Sill controls address the risks named in four public security frameworks: OWASP Top 10 for LLM Applications (2025), OWASP Top 10 for Agentic Applications (v1.0, 2025), MITRE ATLAS (2026.05), and NIST AI RMF 1.0. Sill holds no SOC 2 attestation, no PCI ROC or SAQ, and no ISO 27001 certification, and will not claim any until accredited audits complete.

Mapping is not certification

A mapping cell asserts only that the named Sill control addresses the named framework risk, per Sill’s reading of the public control descriptions. Conformity assessment under any standard requires an accredited audit. The marketing copy, the audit bundle’s control-framework mappings section, and this page are all subsets of one canonical control table; none of them is a certification.

This is a deliberate posture. Sill is a trust product — overclaiming is the failure mode that erodes credibility with the buyers the product serves. The honest statement is: mappings now, audits later.

What Sill maps to

Framework	Version mapped	Upstream
OWASP Top 10 for LLM Applications	2025 (v2.0)	genai.owasp.org
OWASP Top 10 for Agentic Applications	v1.0 (2025-12-10)	genai.owasp.org
MITRE ATLAS	2026.05	atlas.mitre.org
NIST AI RMF	1.0 (+ GenAI Profile AI 600-1)	nist.gov/itl/ai-risk-management-framework

The canonical, control-by-control mapping table — every policy rule and verifier-layer control, with shipped/planned status and per-framework cells — is published at sill.so/standards. A new upstream framework release triggers a delta review; the dashboard’s reporting view reflects the version Sill is currently mapped against.

flowchart LR
    A[Sill control catalog] --> B[Framework mappings]
    F[OWASP LLM 2025] --> B
    G[OWASP Agentic v1.0] --> B
    H[MITRE ATLAS 2026.05] --> B
    I[NIST AI RMF 1.0] --> B
    B --> C[sill.so/standards]
    B --> D[Audit bundle mappings section]
    B --> E[Dashboard reporting view]

What each framework mapping covers

OWASP LLM Top 10 (2025)

The OWASP Top 10 for LLM Applications is the canonical risk list for LLM-integrated systems. Sill’s mapped coverage focuses on the risks where an authorization layer in front of agent traffic can do useful work:

LLM01 Prompt Injection — instruction-override detection (r10) and Unicode tag-block detection (r20).
LLM02 Sensitive Information Disclosure — inbound credential-leak detection (r22) and outbound output sanitization (r21); semantic leakage is out of architectural scope.
LLM06 Excessive Agency — the bulk of the policy catalog: signed-mandate requirement, per-transaction and daily spend caps, human-in-the-loop on destructive actions, cart-ceiling and cart-currency checks, subscription-consent and delegation-window guards.
LLM10 Unbounded Consumption — per-agent and per-IP rate limits, aggregate rate caps, mandate-body size limits, evaluation budgets, and the emergency kill switch.

Risks Sill does not claim to address (model training/RAG poisoning, embedding attacks, model-output misinformation) are out of architectural scope; the marketing site lists them explicitly.

OWASP Top 10 for Agentic Applications (v1.0)

The OWASP Top 10 for Agentic Applications (v1.0, 2025-12-10) is the agent-specific companion list. Sill’s mapped coverage:

ASI03 Privilege Compromise and ASI10 Overwhelmed Human-in-the-Loop — covered (allowlisting, signed-mandate requirement, HITL routing, per-customer data scoping).
ASI01 Memory Poisoning, ASI02 Tool Misuse, ASI04 Resource Overload, ASI06 Identity Spoofing & Trust Manipulation, ASI08 Repudiation & Untraceability, ASI09 Misaligned & Deceptive Behaviors — partial.
ASI07 Misaligned Inter-Agent Communication — covered for registered-agent delegation (delegation-chain verification, r29). NOT covered for unregistered or cross-registry agents; Sill never claims absolute ASI07 coverage.
ASI05 Unexpected Code Execution — out of scope. Sill is an authorization layer, not an execution sandbox.

MITRE ATLAS (2026.05)

MITRE ATLAS is the adversarial-tactics knowledge base for AI systems, modelled on ATT&CK. Sill maps to it at the tactic level (Initial Access, Evasion, Exfiltration, Impact, Credential Access, Discovery) and at the technique level where confirmed against the 2026.05 dataset:

AML.T0096 (Verify Attacker-Controlled AI Service for C2) — covered, via the mandate verifier (signature, identity registry, protocol allowlist).
AML.T0011.002 (Poisoned Agent Tool) — partial, via skill-manifest pinning (r18).
AML.T0098 (Discover Agent Authentication Credentials) — partial, via inbound credential DLP (r22).
AML.T0051 (LLM Prompt Injection) — partial, via instruction-override and Unicode tag detection (r10, r20).
AML.T0100 (AI Agent Clickbait) — partial only; poisoned content typically reaches the agent before Sill’s mandate boundary.

NIST AI RMF 1.0

NIST AI RMF 1.0 (and the GenAI Profile AI 600-1) defines four core functions: Govern, Map, Measure, Manage. Sill’s signed, Merkle-chained audit envelope and bundle export support the Measure and Manage functions: every mandate evaluation produces a tamper-evident record that an external auditor or risk owner can verify and incorporate. Sill maps at function level pending a subcategory-level pass with counsel.

How a control becomes a mapping row

The control catalog is the canonical source. A policy rule, verifier-stage check, audit feature, or webhook handler enters the mapping table only when it is shipped — meaning enforced in production code paths. The mapping table itself never asserts more than the catalog supports, and external surfaces (the Standards page, the audit bundle’s control-framework mappings section) assert subsets of the canonical table, never supersets.

sequenceDiagram
    participant Rule as Policy rule / control
    participant Catalog as Control catalog (shipped / planned)
    participant Public as sill.so/standards + audit bundle

    Rule->>Catalog: ships in production
    Catalog->>Public: status change → published mapping cell
    Note over Public: External claims are subsets, never supersets

PCI scope

PCI scope is architecturally minimal: Sill handles only opaque processor tokens (Stripe pm_* / tok_* and Shared Payment Token references). Raw card numbers (PANs) never enter any Sill system. This is enforced by:

Architecture — the merchant’s processor (Stripe) holds the card, authorizes the charge, settles, and pays out. Sill never custodies funds.
CI gate — a repository-wide grep against PAN-shaped patterns blocks any code or fixture that would introduce raw card data.

This is not a PCI certification claim. Sill holds no PCI attestation, ROC, or SAQ. PCI certification remains TBD until an accredited assessment completes. See Security for the architectural detail and Stripe’s PCI guidance for the processor side.

Compliance items that are not (yet) claims

The following are deliberately not asserted as present-tense capabilities. They are listed here so it is unambiguous what Sill does and does not claim today:

SOC 2 — no attestation today. Pilot-grade preparation is planned work.
ISO 27001 / 27701 — no certification today.
PCI DSS — no certification today (see PCI scope above for the architectural posture).
EU AI Act — alignment posture is being developed; no formal claim today.
GDPR — formal processor / DPA posture is in progress; no formal claim today.
Data residency / merchant-controlled region — Phase 1 is US-East only. Multi-region is on the roadmap, not a current capability.
External penetration test — open compliance gate; not done at the time of writing.

When any of these moves, it will land first in the canonical mapping document and then in this page — never the other way around.

Frequently asked

Is the framework-mappings page a substitute for SOC 2 / PCI / ISO 27001?

No. A mapping is one party (Sill) stating where its controls address a public risk list. A certification is an independent, accredited audit. Sill does not market mappings as certifications and will not until accredited audits complete.

Why these four frameworks specifically?

OWASP LLM Top 10 and OWASP Top 10 for Agentic Applications are the two industry consensus lists for the risk surfaces Sill exists to govern. MITRE ATLAS is the adversarial-tactics knowledge base auditors and red teams use. NIST AI RMF is the function-level governance framework most procurement reviews ask about. They are the smallest set that covers what reviewers actually ask about for AI-agent authorization.

Where does the agent-card / mandate / audit signing fit in compliance terms?

The cryptographic surface (ed25519 on the agent card, ARD trust manifest, and audit record; the public JWKS at https://edge.sill.so/.well-known/jwks.json) is what makes the audit envelope verifiable by a third party. That verifiability is what supports the NIST AI RMF Measure/Manage mapping and the audit bundle’s control-framework mappings section. See Verify a signature for the recipe.

How does Sill keep its mappings current with upstream releases?

A framework-watch routine diffs the published frameworks against a tracked version manifest and opens a delta review when an upstream release lands. The mapping document is updated in the same change as any rule whose status affects it.

Can a customer use Sill’s mappings in their own SOC 2 / ISO audit?

The mappings, the audit bundle, and the public verifier path are designed to be reusable evidence for a customer’s own audit (the customer’s auditor decides what to accept). Sill provides the signed records and the verification recipe; the customer’s auditor decides what they support.