Security & data protection

Controls you can verify, evidence you can hand over.

Udal is engineered for air-gapped, accreditation-sensitive deployment. This page summarises the platform's technical controls, the evidence it generates, and the boundary between what Udal provides and what your organisation owns.

  • Fail closed by default
  • Tamper-evident audit
  • Accredited profile

Design principles

Four principles behind every control

A control you cannot verify is not a control you should accept. These principles are what the rest of the platform is built to enforce.

  1. 01

    Fail closed

    Security-relevant defaults deny. An empty authorisation policy denies everything, an unreachable policy engine denies, and a misconfigured accredited install refuses to start rather than run insecure.

  2. 02

    The control plane runs no untrusted code

    Agent code executes only inside isolated, hardened, sandboxed pods — never in the control-plane process.

  3. 03

    An agent never exceeds its caller

    Every tool an agent invokes is authorised against the caller's granted scopes at the point of execution.

  4. 04

    Everything security-relevant is evidenced

    Identity, authorisation decisions, approvals and changes land in an immutable, tamper-evident audit log mapped to control frameworks.

Control domains

Nine domains, documented in detail

A control-by-control assessment with source traceability is available to your security team under NDA.

Identity & access

  • OIDC (Authorization Code + PKCE), SAML 2.0 and LDAP / Active Directory as first-class identity providers
  • SCIM 2.0 provisioning with group-to-role mapping; unmapped groups are dropped by default
  • Asymmetric JWT verification (RS256 / EdDSA) against the IdP's JWKS, with pinned algorithms and bound iss/aud
  • HttpOnly console sessions and server-validated CSRF tokens on state-changing requests
  • No anonymous access: the runner refuses to start if authentication is required but unconfigured

Authorisation & policy

  • Open Policy Agent decision point evaluated on every tool call
  • Fresh installs ship a deny-all grant map; empty or missing scopes deny
  • The tool server re-checks policy before any side-effecting tool executes
  • Separation of duties enforced: approver ≠ submitter, with single-use, time-limited approval links
  • Deploying agents and governance admin are gated behind explicit deployer and admin roles

Workload isolation

  • Each run is dispatched to its own short-lived Kubernetes Job or pod
  • Pods run non-root, read-only root filesystem, all capabilities dropped, seccomp RuntimeDefault, no service-account token
  • gVisor / Kata RuntimeClass kernel sandboxing; the accredited profile refuses to schedule without it
  • Import allow-list constrains which modules a manifest may load
  • Default-deny NetworkPolicy prevents lateral movement and unrestricted egress

Service-to-service

  • Short-lived, signed, audience-bound service tokens per internal call
  • Project identity bound to verified claims, never a spoofable header
  • Model gateway routes only to an allow-list of in-boundary backends; unknown models are rejected
  • Under the accredited profile the gateway and tool server refuse to start without service auth

Data protection

  • Guardrails screen inputs against a pluggable PII and content classifier at model and tool boundaries
  • The accredited profile refuses the development heuristic classifier and requires a real one
  • Tool arguments are constrained to declared input schemas rather than forwarding run state
  • Audit and SIEM feeds carry governance metadata only — never run inputs or model content
  • Air-gap posture via private endpoints; no customer data is used to train models

Audit & monitoring

  • HMAC-keyed, tamper-evident audit chain with offline verification (udal audit-verify)
  • Real-time forwarding to Splunk HEC, Datadog, Elasticsearch or a generic HTTP collector
  • Prometheus metrics with shipped ServiceMonitors, Grafana dashboards and alert rules
  • Support bundles enforce redaction in code: allow-listed config, secret presence only, run content dropped

Cryptography

  • Asymmetric identity (RS256 / EdDSA) and Ed25519 licence verification; the deploying party holds no signing secret
  • HMAC-sealed evidence reports alongside the keyed audit chain
  • TLS 1.2/1.3 throughout, with modern TLS policy at the edge

Supply chain & change control

  • Signed release images pinned to digests, enforced in-cluster by a shipped Kyverno verifyImages policy
  • Least-privilege CI with reproducible, lockfile-pinned builds
  • Unsigned or unpinned images are rejected by the cluster

Resilience & recovery

  • Temporal-backed durable execution: runs, approvals and long-running work survive restarts
  • Multi-AZ managed PostgreSQL, HPA/PDB templates, three-AZ subnet topology
  • Scheduled backups with a documented restore runbook and post-restore audit verification
  • Scheduled sealed evidence reports retained on persistent storage

Accredited profile

One switch for the regulated posture

A regulated install sets UDAL_PROFILE=accredited. The platform then refuses to start unless the secure configuration is in place, so a missed setting fails loudly at deploy time instead of shipping insecure.

  • Asymmetric identity and licence verification; symmetric paths refused
  • Authentication required across mutating and data-returning endpoints
  • Service auth required and configured for gateway and tool server
  • A real PII/content classifier required — no development heuristics
  • Kernel sandbox RuntimeClass required before any agent pod is scheduled

Evidence

Sealed, control-mapped reports

The platform generates a sealed evidence report from its own audit chain, RBAC and configuration — in the console Compliance tab, via the CLI, or as a scheduled offline export.

  • SOC 2

    Trust Services Criteria CC6.1–6.7, CC7.2–7.3, CC8.1, A1.2

  • ISO/IEC 27001:2022

    Annex A A.5.15/16/18/31, A.8.2/15/16/24/32

  • NIST SP 800-53 Rev. 5

    AC-2/3/5/6, AU-2/9/10, CM-3, IA-2, SC-13/28

Shared responsibility

An explicit boundary

Acceptance should be based on accurate state. We are deliberately clear about which controls are ours and which remain with the deploying organisation.

Udal provides

  • Technical agent-platform controls: access, authorisation, isolation, cryptography, audit and separation of duties
  • Automated, tamper-evident evidence mapped to SOC 2, ISO/IEC 27001:2022 and NIST SP 800-53
  • The accredited profile, which enforces the secure configuration at startup

You own

  • Identity provider configuration and the group-to-scope grant policy
  • Key rotation and KMS custody, cloud authorisation boundary, network perimeter and data-residency sign-off
  • Governance and policy, personnel security, incident response, business continuity and vendor risk
  • Confirming at-rest encryption and region attestations, and running a tested restore drill
Request the full security overview
Northern sea cliffs and dark water at evening

A more capable, sovereign future.

Put AI agents to work in your environment, with complete control.

Book a demoExplore the platform
  • Sovereign AI
  • Smarter organisations
  • Brighter tomorrows