Security by architecture, not badge theater.
The most sensitive thing in an executable-docs platform is the credential that makes execution work. Ours never leaves the server. Instead of a gated badge wall, here’s what we actually do — controls you can read.
No NDA to read this page. No certification claimed that we haven’t earned.
# the agent acts through your docs — the key stays on our server → authenticated GET (auth injected server-side) ← 200 OK real data · the model never saw the credential → write attempt POST (writes off by default) ← 403 "Writes are disabled for this API target." → asks for the API key… ← never returned. not in the tool, the transcript, the response, or a log.
What’s in place — and what isn’t yet
We’d rather show you controls you can read than badges we haven’t earned. Both columns are honest.
In place today
- ✓ Credentials injected server-side — never in a tool definition, transcript, response, or log line.
- ✓ Outbound execution passes an SSRF-guarded executor, covered by its own test suite.
- ✓ Agent actions are read-only by default; writes are opt-in per project and 403 until you turn them on.
- ✓ PII and secrets are redacted twice, then burned into screenshot pixels — unrecoverable from the stored asset.
- ✓ Self-host the entire platform inside your own infrastructure.
- ✓ Role-based access, versioned publishing with approvals and rollback.
Not earned yet
- ○ SOC 2 and ISO 27001 certification — not in place today.
- ○ An independent third-party penetration test — not commissioned yet.
- ○ When either lands, it shows up here with a date. Not before.
If a certification is a hard requirement for you, tell us — self-hosting removes most of the question.
How credentials work
When an agent calls your API through Atloria — the executable-MCP model — the owner configures the credential once, and Atloria injects it on our server at execution time. It never reaches a model, a browser, an MCP config file, or a log line.
The usual way
- ✕ Key pasted into the agent’s config file — in plaintext.
- ✕ Long-lived; rotated by hand, if anyone remembers.
- ✕ Every tool the agent loads can read it.
Atloria
- ✓ Configured once, by the owner, on our server.
- ✓ Injected at execution time — never in the tool, transcript, or response.
- ✓ Read-only by default; writes opt-in; every call SSRF-guarded.
We tested this end-to-end rather than asserting it — the receipt in the hero is the behaviour, not a promise. The full mechanism lives on the agent actions page.
The SSRF-guarded executor
Every outbound call an agent makes passes a single, bounded executor. It’s covered by its own test suite so the safety properties are enforced, not documented and forgotten:
- ✓ Blocks private, loopback and metadata hosts — no reaching back into your internal network.
- ✓ Read methods are always allowed; anything that writes is 403-shaped unless you opt in.
- ✓ Auth is injected server-side and never returned in the response body.
- ✓ A blocked write is a polite refusal the agent can reason about — not a side effect.
Read-only by default
A fresh project can only read. Non-GET operations return a 403 until an owner explicitly enables writes per project.
So the worst case for a misconfigured or over-eager agent is a refusal, not a change to your data.
Redaction, by design
When the recorder widget captures a real user’s flow, secrets and PII are scrubbed before anything is stored — in three passes, and then permanently in the pixels.
1 · At capture
Client-side, before it leaves the browser: password fields, and token / email / card patterns are scrubbed on the way out.
2 · On store
A server re-scan catches emails, card numbers, JWTs, bearer / API-key blobs, and field-name hints (password, secret, token, otp, cvv, ssn, pin).
3 · On every read
Public flow reads are re-redacted, so nothing sensitive can slip through a later fetch.
Burned into the pixels. The screenshot pipeline paints redaction boxes into the image itself — a redacted region can never be recovered from the stored asset. There is no clean original sitting behind a black rectangle.
What we store from your repo
Exact and boring on purpose. Atloria parses your code to generate docs; it keeps the artifacts of that parse, not a mirror of your source.
Generated documentation
The pages, reference and manuals Atloria produces from your repository.
The code entity graph
Functions, types, endpoints and their relationships — extracted by the parsers, not your raw secrets.
Citations
The source location behind each generated statement, so every claim traces back to code.
Captured screenshots
Images taken while an agent drives your app — with PII and secret regions already burned out.
Deletion removes a project and its generated artifacts. Want the precise retention and deletion path for your review? Ask us — we answer directly, not from behind a form.
AI and your data
Generation and grounded answers run on Microsoft Azure’s enterprise AI services — not a consumer chat product. Here is every subprocessor and exactly what it touches. Have a specific data-processing question? Ask; we’d rather answer it than gate it.
Microsoft Azure — Blob Storage
Stores generated assets and the screenshots captured while building your manuals.
Microsoft Azure — OpenAI / AI services
Runs model inference for documentation generation and grounded answers, on Azure’s enterprise AI services — not a consumer chat product.
Microsoft Azure — AI Search
Backs the retrieval index that grounds search and cited answers over your published docs.
Run it in your own infrastructure
If the answer is still no, run it yourself. The entire platform is self-hostable, so your code and your generated docs never leave your infrastructure — and the whole subprocessor question above becomes yours to answer.
Talk to us about self-hosting →Found something? Tell us.
Responsible disclosure keeps everyone safer. Email security@atloria.dev with the details and we’ll work it with you.