Security

Effective 2026-09-03. Read alongside Privacy, which this page does not contradict — it describes the same system from the security side.

What crosses the wire

Every call is the same shape: your agent sends a question — a key it wants read, or an action it wants to take — and Ogen answers with a verdict: a resolved value, an honest "ambiguous" with every candidate, "unavailable," or a hold waiting on a named person. The question and the verdict are the whole payload. Nothing about how a verdict was reached is ever part of the response.

Every page you load — every one, not a subset — enforces a Content-Security-Policy: a browser-level rule naming exactly which script and style may run, so an injected one is refused outright rather than merely logged and left running.

What we store and don't

Stored

Your account, key hash, and tier.
Bindings — the key names you track and where each one's live source is, never the data at that pointer.
Registered actions — the kind, the key it depends on, and how costly it is to reverse, never the action's own logic.
Day-bucketed activity counts and pending/decided confirmations.

Never stored

The values your live source returns — read when asked, used once, discarded.
A log you paste into the "Send us a log" tool on the landing page — that request computes a count and discards the log; nothing about its content is written anywhere.
Plaintext credentials — see Credentials, below.

Credentials

Your API key is stored as a SHA-256 hash. The raw key is shown once, at the moment it's minted, and never again — not on a page, not in an email you can look back at twice, not in a log.
Credentials for your own bound sources — an auth header, a connection secret — are encrypted at rest with AES-256-GCM under a key held only by the pod that serves your tenant. The plaintext exists only for the instant of the outbound read to your source.
An approver's email address — the one you register so a hold can reach a named person — is encrypted at rest with AES-256-GCM under that same key. The plaintext exists only for the instant of addressing a notice or a sign-in link to them.
An approver who sets up a passkey leaves us public key material only. Nothing that could decide in their place, and no biometric, ever leaves their device; turning the approver off turns the passkey off.
No credential — yours or a source's — is ever logged, and no tool or page ever returns one back to a caller. What you gave us to reach your source stays write-only from the outside.
A client that signed in instead of pasting a key holds an OAuth access token issued by our identity provider, never by the pod. The pod does not store, sign or cache tokens: each request is checked with the provider at that moment, and a revoked sign-in stops on its next call. Your tenant sees a signed-in person as one key row it can revoke.
Ogen Assist runs on your own model-provider key, stored the same way and cleared when you turn Assist off. While it is on, the values behind a held action go to your provider and nowhere else; the draft that comes back lives only as long as the hold. A value that reads like an instruction is never acted on, and no answer from the model can fill a field a person must fill. An operator kill switch pauses the model step without touching a single hold.

Data flow

One question in, one verdict out — your data never rests in the middle.

Your agent

asks a question

→

Ogen

reconciles, never guesses

→

Your live source

read fresh, every time

→

A verdict

back to your agent

Isolation

Every key belongs to exactly one tenant, and every binding, action and activity record is scoped to that tenant's id. One tenant's key never resolves another tenant's data, and the encryption key protecting a bound source's credentials is a pod-level secret, not a per-request value that could leak across tenants.

What we ask of you

Bind sources over https only.
Give Ogen read-only credentials wherever your source supports scoping them down — Ogen only ever needs to ask a question, never to write.
Treat your API key the way you'd treat any bearer credential: it's shown once, so store it somewhere real.

Reporting a concern

We don't publish an address. If you find something you think is a security issue, use the "Talk to us" form in the pricing section of the landing page — it reaches the team directly.