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 Agentic Applications (2026, v1.0), OWASP Top 10 for LLM Applications (2026), MITRE ATLAS (2026.07), and NIST AI RMF 1.0. The Agentic Top 10 is Sill’s primary OWASP reference: OWASP’s 2026 editions draw the scope line explicitly — the LLM Top 10 covers the model as a component, the Agentic Top 10 covers the model as an actor with tools and downstream consequences, which is the boundary Sill governs. 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 Agentic Applications	2026 (v1.0, 2025-12-10)	genai.owasp.org
OWASP Top 10 for LLM Applications	2026	genai.owasp.org
MITRE ATLAS	2026.07	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]
    G[OWASP Agentic 2026] --> B
    F[OWASP LLM 2026] --> B
    H[MITRE ATLAS 2026.07] --> 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 Top 10 for Agentic Applications (2026, v1.0)

The OWASP Top 10 for Agentic Applications (2026, v1.0, published 2025-12-10) is the agent-as-actor risk list — Sill’s primary OWASP reference. Sill’s mapped coverage:

ASI03 Identity & Privilege Abuse and ASI10 Rogue Agents — covered (agent allowlisting, ed25519 mandate verification, per-customer data scoping, key revocation).
ASI01 Agent Goal Hijack, ASI02 Tool Misuse & Exploitation, ASI04 Agentic Supply Chain, ASI06 Memory & Context Poisoning, ASI08 Cascading Failures, ASI09 Human-Agent Trust Exploitation — partial.
ASI07 Insecure 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.

OWASP LLM Top 10 (2026)

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.

MITRE ATLAS (2026.07)

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.07 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) and AML.T0054 (LLM Jailbreak) — partial, via instruction-override and Unicode tag detection (r10, r20). Sill guards the action boundary after a jailbreak; it does not prevent the jailbreak itself.
AML.T0113 (Steal Web Session Cookie) and AML.T0091.001 (Use Alternate Authentication Material: Web Session Cookie) — partial, via inbound session-cookie DLP (r22) and outbound response sanitization (r21, which also strips the rendered-output theft markup). Anomalous-source detection on a live session is future work.
AML.T0100 (AI Agent Clickbait) — partial only; poisoned content typically reaches the agent before Sill’s mandate boundary.
AML.T0114 (AI Service Web Interface as C2 relay) — not covered; the technique’s precondition (an anonymous public AI web interface with browse/summarize/URL-fetch) does not exist in Sill.

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. A data-subject deletion mechanism is live (owner-requested account deletion with a 30-day grace window, then erasure of personal data with the signed audit chain retained anonymized — see Security → Data retention and deletion); the formal DPA / processor documentation around it is still being finalized.
Data residency / merchant-controlled region — US-East only today. 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 Top 10 for Agentic Applications and OWASP LLM Top 10 are the two industry consensus lists for the risk surfaces Sill exists to govern — the Agentic list (agent as actor) is Sill’s primary reference, the LLM list (model as component) is secondary, per OWASP’s own 2026 scope split. 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.