Security overview
How NobleCloak handles AI model usage and tenant isolation, as public commitments. This page promotes our internal engineering standards to customer-facing prose — it states the commitments we hold ourselves to, not an incident history.
AI model usage
Training data is excluded — the only mode
Model inference runs on Amazon Bedrock. Under Bedrock's terms, customer
inputs and outputs are excluded from training the underlying foundation
models. This is not a setting we turn on: it is the only mode NobleCloak
operates in, and there is no per-account toggle to change it. See the
trains_on_data_by_default claim on the Overview page for the
underlying claim and citation.
Invocation logging is disabled by default
Logging of AI model invocations — the request and response payloads sent to
and from a model — is disabled by default across our platform. That default
is enforced in infrastructure-as-code rather than left to manual
configuration, so it cannot silently drift on. This describes invocation
logging specifically, not a general customer-content retention commitment;
see the zero_data_retention_available, customer_content_retention and
human_review_of_customer_data claims on the Overview page for the
gaps we have not yet closed there.
Model access is scoped, and region routing fails closed
Our infrastructure grants access to specific, approved model families rather
than broad model-provider access, and inference calls are routed exclusively
through US AWS regions. If US-region routing is unavailable, the call fails
closed — it errors rather than silently falling back to a model hosted in
another region. This is a code-enforced routing control, not a contractual
at-rest data-residency commitment; see the data_residency_options claim on
the Overview page for how we scope that distinction.
No static AWS credentials
Our platform's services authenticate to AWS and to one another using workload identity (short-lived, per-workload credentials issued by the platform, via IRSA) rather than long-lived static credentials. No static AWS credentials are used anywhere in the platform for machine-to-machine access to AWS. This does not describe every third-party integration — some providers we call are only reachable via a static API key or OAuth client secret they issue, held as a platform secret rather than an AWS credential.
Audit logging
Every organization has access to the Execution Ledger, an org-scoped,
customer-facing audit log viewable in-product and exportable as a CSV file.
It is not a SIEM streaming integration — there is no programmatic push to an
external log destination today. See the audit_log_availability claim on
the Overview page for how we scope that distinction.
Tenant isolation
We document five tenant-isolation tiers, ranging from shared multi-tenant infrastructure with logical (row-level) separation up to a fully isolated AWS account running its own dedicated Kubernetes cluster:
| Tier | Isolation model |
|---|---|
| 0 | Shared database and compute; logical (row-level) tenant separation |
| 1 | Shared compute; isolated per-tenant database schema |
| 2 | Isolated database; shared compute cluster; tenant-scoped credentials |
| 3 | Dedicated compute namespace within a shared cluster |
| 4 | Fully isolated AWS account with its own dedicated cluster |
Dedicated-account and on-premises deployments (tier 4, and above the table
for on-prem) are provisioned per engagement — they are not a self-serve
purchase today. See the tenant_isolation and deployment_models claims on
the Overview page for the claims this backs.
What this page does not cover
This page describes engineering controls we have built and enforce. It is not a compliance certification. We do not currently hold a SOC 2 report or ISO/IEC 27001 certification — see the Overview page for our current attestation status, published alongside everything we cannot yet affirm.
Last updated: 2026-07-27