Scale – From personal AI to organisational AI: why copilots plateau, and what an AI operating system changesRegister →
Trust Centre

You stay in control

Scrydon is built so that security is the default, not an add-on. Every external request crosses five gates before it reaches any service, the platform ships fail-closed, and your data, keys and AI stay inside your perimeter.

How it is securedCompliance & evidence

Fail-closed by default

If a check cannot be satisfied, access is denied. The secure outcome is the standard outcome.

Your keys, your perimeter

LOCAL, BYOK and HYOK key strategies keep encryption — and trust — on your side.

Provable & auditable

Immutable audit and framework evidence packs make control demonstrable, not just claimed.

Security by architecture

Five gates, then fail-closed

Defence-in-depth is not a slogan here. Every external request crosses five independent gates before it ever reaches a service. Each gate is designed to deny by default, so a misconfiguration or a missing grant blocks access rather than quietly granting it.
  1. 1

    Ingress hardening

    Forged identity headers are stripped at the edge. Internal identity is never trusted from the outside; it is established inside the perimeter.

  2. 2

    Authorisation

    A single policy decision point evaluates every request as policy-as-code (Rego) across both the application and data planes.

  3. 3

    mTLS service mesh

    Services authenticate one another with mutual TLS. No shared bearer tokens, no implicit trust between workloads.

  4. 4

    Secrets management

    Credentials are encrypted at rest, scoped per grant and redacted in logs. A secret read without a valid grant fails outright.

  5. 5

    DLP & audit logging

    Outputs pass through the guardrails engine and every privileged operation is written to an immutable, queryable audit trail.

Fail-closed by default. Invalid mTLS identities are rejected, failed authorisation checks deny access, and workflows run under server-issued grants — never under user-supplied identities.

Data protection & DLP

The guardrails engine

Data loss prevention is the fifth gate. Before any model output leaves the platform it passes through the DLP guardrails engine, which scans for personally identifiable information, flags potential hallucinations and validates against regex patterns and JSON schemas. What does not pass does not leave.
  • PII detection: Model outputs are scanned for personally identifiable information before they leave the platform.
  • Hallucination flags: Responses are checked against grounding so unsupported claims can be flagged or blocked.
  • Regex & JSON gates: Pattern and schema validation enforce the exact shape of what may be returned.
  • Exfiltration control: Guardrails sit on the egress path, preventing sensitive data from escaping in a response.
Identity & access

Zero-trust identity

Access is governed by a single policy decision point that evaluates every request as policy-as-code. Identity is layered into three tiers — organisation roles, workspace membership and team grants — and integrates with your existing SSO and SCIM so joiners, movers and leavers are handled automatically.

Explore the underlying sovereign identity layer.

  • Zero-trust by default: Workflows run under server-issued grants, never under user-supplied identities.
  • SSO & SCIM: Connect your identity provider for single sign-on and automated user provisioning and de-provisioning.
  • Three-tier model: Organisation roles, workspace membership and team grants compose into least-privilege access.
  • Multi-tenant isolation: Tenants are isolated by design, so one organisation can never reach another's data.
Your keys, your perimeter

Encryption on your terms

You choose how far trust extends. Scrydon supports three key strategies, and external AI vendors are always opt-in — the platform can run air-gapped from public cloud, entirely inside your perimeter, until you decide otherwise.

LOCAL

Platform-managed encryption. Credentials are encrypted at rest and redacted from every log line — the fastest path to a hardened default.

BYOK — bring your own key

You supply the encryption keys. Scrydon uses them to protect your data while you retain ownership and the ability to revoke.

HYOK — hold your own key

Keys never leave your custody. The platform operates against keys you hold, keeping ultimate control firmly on your side of the line.

External AI is opt-in. No request leaves for a third-party model unless you have explicitly allowed it, so sovereignty is a setting you control rather than a promise you have to trust.

Audit & accountability

An immutable record

Every privileged operation emits an immutable, queryable audit entry — capturing the actor, their IP address and the action taken, retained according to your policy. Because the trail is append-only, the record of what happened cannot be quietly rewritten, giving you and your auditors a single, trustworthy source of truth.

Accountability is governed end-to-end by AI Governance, which ties policy, identity and audit into one control plane.

Open standards

The Agent Control Standard

Agent oversight should not be something each vendor invents for itself. The Agent Control Standard (ACS) is a vendor-neutral, community-governed standard, developed in the open and hosted at OWASP, for how an agent reports a step before it acts and a Guardian answers: allow, deny, modify, ask or defer. Scrydon implements the ACS v0.1.0 wire contract, so every governed agent turn crosses that boundary — signed, recorded and fail-closed.

Scrydon implements ACS v0.1.0

Fail-closed, and not negotiable downwards

Scrydon negotiates a deny-on-failure posture and returns it as a floor no counterparty can lower. A timeout, an invalid signature, a malformed response or an unconfirmed state write stops the action rather than letting it through. An unguarded outcome is recorded as exactly that, and is never treated as permission.

Signed, and replay-protected

Every request carries its own identity, timestamp and nonce, signed over a canonical envelope with a key derived per session — the root secret never travels on the wire. Duplicate identities, reused nonces, requests outside the agreed clock skew, and any caller whose view of the session disagrees with the durable record are all refused.

A decision record you cannot rewrite

Requests that carry content advance a tamper-evident per-session chain, and denials are written to the immutable audit trail as a governance finding — reaching your SIEM over the signed delivery you already have configured. Closing facts cannot retroactively veto work that has already completed.

What Scrydon does not claim

A conformance profile is declared only when the running deployment actually has the methods, algorithms and sinks behind it: inventory-inspection and asymmetric-crypto profiles are refused when policy is constructed rather than advertised. Signed control today covers the agents Scrydon hosts; a Guardian your own organisation operates needs asymmetric signing that this deployment does not yet offer.

Read the ACS implementation notesThe standard itself: agentcontrolstandard.org

The standard is Apache-2.0 licensed and governed by community consensus; Scrydon is an implementer of it, not its owner.

Compliance & evidence

Controls that map to the frameworks you answer to

Scrydon's controls are designed to map to and support the regulatory and assurance frameworks European organisations face. The platform produces framework evidence packs so you can demonstrate control during your own audits and assessments rather than reconstructing it after the fact.
ISO 27001ISO 42001EU AI ActGDPR
SOC 2
SecNumCloudDORANIS2
NIST
CRA
AIUC-1

See the full compliance overview for the detail behind each mapping. Scrydon describes how its controls support these frameworks and produces evidence packs; it does not claim formal certification on your behalf.

FAQ

Frequently asked questions

Does Scrydon send my data to external AI vendors?+
No — not unless you decide to. External AI vendors are strictly opt-in. By default the platform can run fully inside your perimeter, air-gapped from public cloud services, and you choose explicitly if and when any external model is allowed.
What does "fail-closed" actually mean here?+
It means the secure outcome is the default outcome. An invalid mTLS identity is rejected, a failed authorisation check denies access rather than allowing it, and a secret read without a valid grant fails with no fallback. Security does not depend on someone remembering to switch it on.
Who can see what was done, and can the record be altered?+
Every privileged operation emits an immutable, queryable audit entry capturing the actor, their IP and the action, retained according to your policy. The trail is append-only, so the record of what happened cannot be quietly rewritten.
Is Scrydon formally certified against these frameworks?+
No — Scrydon does not claim formal certification on your behalf. Its controls are designed to map to and support frameworks such as ISO 27001, ISO 42001, the EU AI Act, GDPR, SOC 2, SecNumCloud, NIST, the CRA and AIUC-1, and the platform produces framework evidence packs to streamline your own audits and assessments. Certification and conformity attach to your specific deployment; refer to the individual compliance pages for the detail of each mapping.