Security
Defence-in-depth across permissions, secrets, audit, network, ingress, and DLP — each layer documented separately so you can review them on their own merits.
Scrydon is built for organisations that have to defend their data, not just use AI on it. Security at Scrydon is layered — every control is enforced in at least two places, and a failure in one layer does not compromise the others.
This section documents the security controls customers can review, audit, and depend on.
Defence in depth
Every external request crosses five gates before reaching any service. Every privileged operation, at every layer, emits to the audit log.
| Layer | Read more |
|---|---|
| Ingress hardening — strips forged identity headers | Ingress hardening |
| Authorisation — single policy decision point across app- and data-planes | Permission model, Authorization |
| Service mesh — all service-to-service calls mutually authenticated; no shared bearer tokens | SPIFFE / mTLS, Network boundary |
| Secrets — encrypt credentials at rest, redact in logs, scope access to approved users | Secrets management |
| DLP — outputs scanned for PII, hallucination, regex / JSON gates | Data loss prevention |
| Audit — immutable, queryable, with full actor + IP context | Audit logging |
Where to start
Permission model
The three-tier hierarchy: organisation roles, workspace membership, and team-based grants.
Secrets management
The three credential strategies — LOCAL, BYOK, HYOK — and where each fits.
Audit logging
What gets logged, what gets redacted, how to query, and how long it's retained.
Data loss prevention
The guardrails engine — PII detection, hallucination check, regex, JSON validation.
Compliance evidence
Every control on this page maps to a framework requirement. If you're preparing for an ISO 27001 / ISO 42001 / EU AI Act / SOC 2 / SecNumCloud / GDPR / NIST / CRA / AIUC-1 audit, see Compliance — every framework page links back to the security controls that satisfy its requirements.
Hardening defaults
The platform ships fail-closed by default:
- Service-to-service requests without a valid mTLS identity are denied.
- Authorisation checks that fail to find a resource return "deny", not "allow".
- Secret reads without a valid grant fail; there is no fallback to environment variables.
- Ingress requests carrying internal identity headers are scrubbed before the request reaches any service.
- Workflows execute under a server-issued execution grant, never under identity passed in the payload.
You don't have to turn defence-in-depth on. It's on. The configuration surface lets you raise individual controls higher (e.g. switch from LOCAL to BYOK, tighten egress, increase audit-log retention) — never lower them below the baseline.