Where your request goes, stage by stage
One TLS connection from your application to obstruo, one from obstruo to the provider. Between them, six stages run in memory. The only things that reach persistent storage are marked below.
Runs in our EU tenancy. The diagram above is the whole path.
Same control plane in your own cloud account. Traffic never crosses our network, control plane stays managed.
Configuration and audit stay inside your estate. Available on Enterprise, scoped per deployment.
Pinned regions, and the ability to refuse anything outside them
Residency claims are worth little if the enforcement is advisory. Each project is pinned to a hosting region for processing and storage, and France is the region available today. The boundary that policy enforces is the EU one: a route that would send traffic to a provider endpoint outside the EU is refused in path, not logged as a warning after the fact. Traffic between EU member states is normal and stays allowed. If a regulator requires a single member state, you can pin the project tighter than the EU. We open further regions when a customer needs one, on a timeline we agree in the contract.
Standard cryptography, unusual care around the keys
The transport and storage encryption is what you would expect and would be unremarkable to specify. The part worth reading closely is key custody: obstruo holds your provider credentials, so they are encrypted per tenant with keys we cannot export, decrypted only in the request path, and never rendered in full to any interface, export or support session.
Raw content lives in memory. Only the redacted version is kept
The prompt as your application sent it exists in memory for the duration of one request, and is released when the response completes. What is written to storage is the post-redaction text, with detected entities already replaced by tokens, so the stored copy is the one your policy considers safe to hold. Teams that would rather hold nothing at all can switch content storage off per project, and teams that genuinely need the original content have to ask for a raw-audit project and accept the risk in writing.
Redacted by default, nothing at all if you prefer
Storing the redacted prompt is what makes an agent debuggable months later without holding personal data. Storing the raw prompt is what most gateways quietly do. Here it is neither quiet nor accidental: a project has to be created as a raw-audit project, with a reason and a signed acceptance of the risk.
Prompts, completions and tool payloads are stored after redaction, with detected entities already replaced by tokens. Raw content is never written.
Set per project, redacted content is discarded with the request and only the decision record remains. Enforcement and audit are unaffected.
A distinct project type for cases that require the original content, such as a regulated investigation. Turned on by you, with a documented reason and an explicit acceptance of the risk.
Long retention is safe because the records hold no personal data
Keeping seven years of audit history is only defensible if that history is not itself a data liability. Decision records carry decisions, versions and counts, so a long retention period costs storage rather than exposure. Redacted content is a separate class with a much shorter default lifetime, and can be switched off entirely. Records are append-only and sealed segment by segment with Transit HMAC-SHA256, so a deletion is detectable rather than deniable.
Your identity provider decides who gets in
Console access is authenticated against your IdP over SAML 2.0 or OIDC, with SCIM provisioning so a leaver is deprovisioned by the same process that handles the rest of your estate. Group claims map to obstruo roles, so membership is managed where you already manage it. MFA is required, and enforced by your IdP policy rather than a second, weaker one of ours.
Separation of duties, including from us
The engineer who ships an agent should not be able to loosen the policy that constrains it, and the auditor reviewing both should not be able to change either. Roles are scoped to the organisation or a single project.
A short list, published, with notice before it changes
Model providers are not our subprocessors. You contract with them directly and we route to the ones you approve. These are the parties that support obstruo itself.
You choose what happens when a control cannot run
The failure mode is the whole product, so it is your decision rather than ours. Redaction and guardrails ship set to refuse, because a control plane that passes traffic through unredacted when its redaction service is unhealthy has quietly become a proxy. Teams that would rather keep an agent running can set either control to warn, degrade or pass through, per project and per environment.
A control layer in the request path has to stay up
Fail closed only works if closing is rare. The data path runs active-active across availability zones, and the control plane is separated from the data path so a console outage never stops traffic.
Active-active across three zones in the project region. Losing one zone costs capacity, not availability.
Policy is evaluated from a local cache in the data path. Console and API deploys do not touch live traffic.
Public status page, named contacts notified within 1 hour, written post-incident review within 5 working days.
How the code that enforces your policy is built
Nothing exotic. Reviewed changes, tested releases, scanned dependencies, and an external look at the parts that matter most.
The documents your review will ask for
These are public and download immediately. If your review needs something that is not here, ask and we will tell you whether it exists yet.
Send your questionnaire to office@obstruo.ai. We answer in your format, not ours, and we will tell you plainly where a control is planned rather than in place.