Skip to content

Trust Center

What we protect, how, and what is still missing.

Putting a gateway in front of your AI traffic is a real trust decision, and it is made by somebody who has been given a questionnaire and a deadline. This page is written for that person. Every control below names the mechanism that enforces it, every date is a commitment rather than an aspiration, and the things we do not have are listed as plainly as the things we do.

INFRO is in private early access. The catalog, the docs, and the API contract are public today, and the gateway is deployed. The console opens with an early-access account, billing opens in stages, and anything beyond v1 is marked Later. Early access details

These are commitments about our own calendar, not claims about an auditor's conclusion. Nothing here says INFRO is certified, because it is not — and where a date is not yet agreed with the audit firm, this page says so rather than estimating one.

No dates are committed yet. An audit firm is engaged for SOC 2. The observation window is not scheduled, so there is nothing here to publish — and we would rather say that than name a quarter we have not agreed with the firm. When it is scheduled the dates appear here, rather than being sent to individual reviewers, so that everyone is holding us to the same commitment. If your timeline depends on it, say so and we will tell you where the scheduling actually stands — sales@infro.io.

SOC 2 Type I

Auditor engaged

An auditor's opinion that the controls described on this page are designed appropriately and were in place on a specific date. It says nothing about whether they operated over time — that is Type II.

Observation begins
Not yet published
Report expected
Not yet published

On completion this page names the audit firm, the report date and the trust services criteria in scope, and the report itself goes out under NDA. Until the report exists, neither the firm nor the scope is claimed here.

SOC 2 Type II

Auditor engaged

An auditor's opinion that those controls operated effectively across an observation window, which is the report most security reviews actually want.

Observation window begins
Not yet published
Observation window ends
Not yet published
Report expected
Not yet published

A Type II window cannot be compressed: the report is only as long as the period it observed. If the window moves, the date here moves with it and the change is stated rather than silently corrected.

ISO 27001

Under evaluation

Certification of an information security management system rather than of a control set. Reviewers outside the US ask for it more often than for SOC 2.

Under evaluation. No auditor is engaged and no date is committed — so there is no date on this page, and there will not be one until there is something to commit to. If ISO is a hard requirement for you, say so in your first email; it is a useful signal and it may change the order we do this in.

We hold no certification today, and nothing above says otherwise. When a report exists this page will name the audit firm, the report date and the criteria in scope, and the report goes out under NDA. Until then what we can offer is the control set below, the answer set, and a straight answer about where the audit actually stands — and if your process needs a report in hand before signature, the right answer is to wait rather than to negotiate.

Each of these is in place now, and each names the mechanism rather than the intention — a database trigger, a binding, a deployed header. Where a control is a policy rather than a mechanism, it says so.

Credentials and keys

Provider credentials are sealed, and bound to one tenant
The provider keys you connect are encrypted with AES-256-GCM under a key held as a Worker secret, never in the database. The organization and connection identifiers are bound in as additional authenticated data, so a sealed credential copied into another tenant's row — or another row of the same tenant — fails closed rather than decrypting. Credentials connected for cost reconciliation are sealed separately, under their own binding.Bound as conn:<organization>:<connection> for inference credentials, and billing:<organization>:<provider kind> for cost-API credentials. A database disclosure on its own opens nothing.
There is no reveal, anywhere
Once a provider credential is saved, no interface returns it — not the console, not the API, not the internal operator console. What either side can see is the last four characters and the timestamps. If you lose the key, you rotate it at the provider; we cannot show it to you.The operator console's connection queries do not select the sealed column at all. A reveal button is the feature that turns one compromised session into every customer's vendor keys.
INFRO API keys are hashed at rest
A gateway key is 32 bytes from a cryptographic random source. What we store is its SHA-256 digest, a display prefix and the last four characters, so a database disclosure does not disclose a usable credential. Revocation writes a tombstone rather than deleting the row, so it cannot be shadowed by a stale cache entry still propagating between locations.SHA-256 rather than a password KDF is deliberate: there is no dictionary to attack against 32 random bytes, and a KDF would add 50-200ms of billed compute to every request.
The encryption key can be rotated without your involvement
Rotating the key that seals customer credentials re-seals every stored credential in place. It does not ask customers to re-enter anything, and the stored algorithm carries a version string so a future scheme can coexist with the current one rather than needing a flag day.Stated plainly: losing that key with no backup is unrecoverable, and every customer would have to re-connect every provider. Backup and recovery are written down as an operational procedure.

Your content

We do not train on your data, and do not sell it
INFRO does not use your prompts, inputs or outputs to train anything, and does not sell them. The providers you connect handle your data under your own agreements and account settings with them — INFRO's logging controls do not change those settings, and cannot.This is the one control on this page that is a policy rather than a mechanism. It is stated in the terms and the DPA, which is where it is enforceable.
Prompt and completion capture is off by default
Request metadata — model, provider, route, token counts, latency, estimated cost — is always recorded, because metering, budgets and governance are what the product is. The content of prompts and completions is not, unless an organization turns capture on. The database column defaults to off; there is no plan on which it defaults to on.org_settings.prompt_logging_enabled, DEFAULT false NOT NULL since the first migration.
The retention window is yours, and the deletion sweep is real
When capture is on, you choose the window — 24 hours, 14, 30, 60 or 90 days, or a year — and what is stored is the shorter of your choice and your plan's ceiling, so a surface can never offer a window the plan will silently ignore. A scheduled job deletes captured payloads once they pass their expiry, in bounded batches so a backlog cannot turn into a long transaction against a table the request path is writing to.Every payload row carries its own expires_at; the purge runs on the platform's minute cron and its lag is one of the conditions that raises an operator alert. Deletion is a DELETE, not a flag.
Trace export is an allowlist, not a copy
If you send OpenTelemetry spans to your own collector, the attribute set is built field by field rather than by spreading a database row, so an internal column added later cannot leak into your observability backend by default. The collector endpoint must be HTTPS, enforced by a database constraint, and the headers you configure are sealed like any other credential.This is the one place INFRO deliberately sends your data to a third-party host you chose, and the one place a leak would be durable. A test asserts internal identifiers are absent from the encoded bytes.

Access and accountability

The audit log cannot be rewritten
Every policy change, credential update, key rotation, plan grant and membership change is a new row carrying an actor and a timestamp. Those rows reject UPDATE, DELETE and TRUNCATE at the database level — not by convention, and not by application code that a support script could bypass. The history of your organization is a record rather than a value.Enforced by a database trigger. Neither an INFRO engineer at a psql prompt nor a compromised application can quietly amend it.
Customer and operator identity share nothing
The customer console and the internal operator console authenticate against two separate systems: separate tables, separate cookie names, separate signing secrets, separate origin allowlists. A customer session presented to an operator endpoint is anonymous there rather than merely under-privileged — it carries a name that system does not look for, signed with a key it does not hold, against a table it does not read.The Worker refuses to start if the two signing secrets are equal or if the two origin lists overlap. Operator sign-up is permanently disabled; accounts are provisioned, and a suspended operator's row is kept precisely so that a check for existence cannot let them back in.
Operator two-factor, and a step-up on destructive actions
TOTP two-factor is available to every operator and is off by default — a deliberate decision, stated here rather than implied. With it on, every operator session must present a code and a password never stands in for one. Independently of that setting, actions that change money, credentials or another operator's access require a second factor presented in the last 15 minutes; where two-factor is off, that step-up is the password. Ten consecutive failures lock the account for fifteen minutes.The proof is a per-session factor row written only by the verification hook, so a session minted in another browser opens nothing. Codes are single-use; backup codes are one-time and stored encrypted.
Two-factor, passkeys and sessions for your own users
Every account can turn on two-factor with an authenticator app and ten one-time recovery codes, and register passkeys or hardware security keys, which sign in on their own or serve as the second step after a password. An owner or admin can require two-factor for the whole organization: a member without it reaches nothing in that organization until they set it up. Single sign-on satisfies the requirement, because your identity provider enforces its own MFA. Every account can see where it is signed in and end any session.Codes are single-use and ten failures lock the account for fifteen minutes; there is no remember-this-device. Removing a factor needs a second factor presented in the last ten minutes, not the password alone. A passkey signs in on its own only if the device verified the user. Emailed and SMS codes are not offered.
Your organization is never read from the request
Console and operator endpoints take the organization from the authenticated session and pass it as an explicit argument, so a call site cannot leave it unstated and a body or query parameter naming an organization cannot become an authorization decision made from attacker-controlled input.A structural test runs real rows through the real response projections with a sentinel value, asserting that internal identifiers and upstream error bodies never reach a customer response.

The platform surface

Security headers on all three surfaces
infro.io, the customer console and the operator console each send a Content-Security-Policy, HSTS, X-Content-Type-Options: nosniff, X-Frame-Options: DENY, a Referrer-Policy, a Permissions-Policy and Cross-Origin-Opener-Policy. The operator console adds a resource policy and a no-index directive, and its sign-in page carries a per-response nonce policy that permits no inline script at all.Verifiable from outside with curl -I against any of the three hostnames. A checked-in script crawls every route with the policy enforced and fails on any violation, so an added third-party origin cannot land silently.
Outbound webhooks are signed, and rotate without a gap
Every webhook we send carries an HMAC-SHA256 signature over the timestamp and the exact raw body, so you can verify both authenticity and that the payload was not altered in transit. During a secret rotation a delivery is signed with both the old and the new secret, so you can adopt the new one without dropping a delivery.Header format INFRO-Signature: t=<unix>,v1=<hex>, documented with verifier code. Signature and timestamp are the reason a webhook is treated as a notification to confirm, never as an authority to act on.
One documented error surface
Every refusal the gateway makes is one of a published set of types and codes, including the ones that are our fault. Requests are size-limited before any parse, with a documented 413 rather than a timeout, and the authentication, sign-in and lead surfaces are rate-limited on the caller's network address.Published in full at /docs/api/errors before you write a line of code against it. Rate limit headers state which are exact and which are an upper bound.
A named subprocessor list, with notice
The vendors INFRO engages are named at /subprocessors, with what each one can actually see and where it runs, and 30 days' notice before a new one begins processing. The AI providers serving your requests are ones you selected and contract with directly — they are not INFRO subprocessors, and the page explains why that distinction is real rather than convenient.Two named infrastructure vendors today. The database runs in Frankfurt and the gateway runs beside it; requests enter Cloudflare’s network wherever the caller is, and the page says so rather than implying a region.

This list exists because the rest of the page is worth less without it. If one of these blocks a purchase, it is a conversation we would rather have in your first email than in week four of an evaluation.

No SOC 2 or ISO 27001 today
Neither is held. An audit needs an operating history to examine and ours is short. The roadmap above is what we have committed to instead; if your process cannot proceed without a report in hand, that is a reason to wait rather than a reason to negotiate.
No independent penetration test
Nothing on this page has been reviewed by anybody outside the team that wrote it. We keep a standing internal security review organised by asset, and it is a self-assessment — which is the difference between having thought about something and having had somebody try it.
No EU-only or regional processing
Requests enter Cloudflare’s network at the location nearest the caller, where TLS terminates, and the gateway itself runs in Frankfurt, next to the database. That placement shortens database round trips; it is not a data-residency control, and region-constrained processing needs infrastructure entitlements we have not bought. A European-looking hostname that does not actually constrain processing is a claim you could falsify in a single request, so we do not serve one.
The hosted service is multi-tenant
On every self-serve plan, organizations share the hosted service and the isolation between them is logical rather than physical. If your requirement is that our software runs in your own infrastructure, that is a self-hosted or hybrid deployment on an enterprise agreement, scoped and agreed per contract; no self-serve plan includes one.
No published uptime SLA on self-serve plans
A service without an operating history cannot honestly publish an availability commitment, so we publish none. An enterprise agreement can carry a contractual SLA with remedies, agreed per contract. Gateway health is checkable from your own browser at /status.
SSO and SCIM are new
SAML and OIDC single sign-on and SCIM 2.0 provisioning are implemented and included from the Business plan, gated on a DNS-verified domain. They have not yet run in production against every identity provider, so we set up the first connection with each customer rather than calling it self-serve.
Guardrails are pattern-based; there are no classifier guardrails
Guardrails for chat completions, included from the Business plan, check prompts and responses against fixed patterns — email addresses, phone numbers, card numbers, IBANs, US Social Security numbers, IP addresses, API keys and terms you list — and block, redact or flag what they match. Pattern matching misses anything outside those formats. Nothing detects prompt injection, jailbreaks, toxicity or off-topic requests, and images, audio and endpoints other than chat completions are not inspected. If your review needs a content classifier on the request path, INFRO does not provide one.
No per-request cost ceiling
Budgets cap the total your organization, a project, a member or a key can reach, and rate limits cap request volume. What does not exist yet is a control that refuses a single unusually expensive request. A legitimate large prompt and an abusive one look the same to the gateway, and a customer would reasonably expect that control.
Rate limits are enforced per location
Limits are counted by Cloudflare’s rate-limiting service at the location where the gateway runs, not by one global counter. The gateway is placed in Frankfurt, so most traffic is counted there, but placement is a routing preference rather than a guarantee, and traffic handled elsewhere is counted separately — so a key can briefly exceed its nominal limit. This is a deliberate trade — the global-counter alternative throttles the largest customer at our architecture rather than at their limit — and the API documentation states which rate limit headers are exact and which are an upper bound.

We list what is not in place as plainly as what is. If a row here blocks a purchase, that is a conversation we would rather have now than after a contract.

No training on your dataCommitted
INFRO does not train on or sell your prompts, inputs, or outputs. Data use by the AI providers you connect follows your agreements and settings with them.
Content logging off by defaultCommitted
Usage metadata supports platform metering, cost estimates and governance. Optional prompt and response logs are off by default, stored separately, and limited by your plan's retention allowance.
Keys hashed at restCommitted
API keys are stored as SHA-256 digests of 32 CSPRNG bytes. A database disclosure does not disclose a usable credential, and revocation writes a tombstone so it cannot be shadowed by a stale cache entry.
Append-only audit logCommitted
Audit rows cannot be updated or deleted — the database itself refuses. Every policy change, credential update, key rotation and membership change is a new row carrying an actor, so the history of your organization cannot be quietly rewritten.
Published subprocessor listCommitted
Infrastructure vendors are named at /subprocessors, with 30 days' notice before a new one begins processing, subject to the emergency exception described there. You select and contract directly with the AI providers you connect.
SOC 2 / ISO 27001Not yet
Not held, and not claimed. A certification needs an operating history to audit and the gateway's is short. What is published instead is the roadmap at /trust: an audit firm is engaged for SOC 2 with no observation window scheduled yet, ISO 27001 is under evaluation with no auditor and no date, and neither is described as anything more than that. Dates appear there when the firm agrees them, not before.
DPA with Standard Contractual ClausesCommitted
Published in full at /dpa, incorporating the SCCs with the UK Addendum. Execution is by email rather than from the console — there is no countersigning flow, and the page says so instead of implying a button.
EU data residencyNot yet
Requires infrastructure entitlements we have not purchased. A hostname that merely looks European is a claim a customer can falsify in a single request, so we will not serve one until processing is genuinely constrained.

Our answers to the questions a security review actually asks — data handling, encryption, key management, access control, monitoring, compliance — published as a plain text document you can read, diff, and paste into your own tooling.

Download the answer setRead it in the browser

It is Markdown rather than a CAIQ spreadsheet on purpose. The CAIQ's value is its question numbering, and a partly-completed one implies membership of a registry we are not in — so this covers the same ground in the order a reviewer reads it, in a format both your tooling and ours can diff. It is generated from the same data as this page, so the two cannot disagree.

Send your own questionnaire as well, in whatever form it takes. We answer every question, including the ones where the answer is no, and say which of those have a date against them. Email sales@infro.io.

Read them before you ask us about them. None of these requires a call, an NDA, or a sales conversation to see.

Data processing agreement
The full text, incorporating the Standard Contractual Clauses with the UK Addendum, including the breach notification obligation and the retention schedule. Execution is by email — there is no countersigning flow in the console, and the page says so rather than implying a button.
Subprocessors
Every vendor INFRO engages, what each one can actually see, where it runs, and 30 days' notice before a new one begins processing. It also explains why the AI providers you connect are not INFRO subprocessors.
Privacy policy
What is collected, the lawful bases, how long each category is kept, and the rights available to a data subject. Paired with the retention windows on this page rather than contradicting them.
Acceptable use policy
What may not be built on the platform, including the categories with no approval path, and what happens when we find out. Written in the card networks' vocabulary because that is who asks.
Terms of service
The commercial agreement, the operating entity and its jurisdiction, and what happens to an account at the end of it.
The error taxonomy
Every refusal the gateway can make, published before you write a line of code against it — including the ones that are our fault rather than yours.
Data handling, in the API reference
Field by field: what is recorded on every request, what capture adds when an organization turns it on, and how the retention window is applied. The engineer's version of the retention control described above.
Keys and authentication
How gateway keys are issued, scoped to a project and an environment, narrowed by role, and revoked — written for the person who has to decide who in your organization gets one.

Found something?

Send it to security@infro.io. That mailbox is read by the people who can fix it, and it is for vulnerability reports rather than support.

  • We acknowledge within one business day and keep you updated while we investigate, including when the answer is that we already knew.
  • Good-faith research is safe here. We will not pursue legal action over testing that avoids privacy violations, service degradation, and destruction or exfiltration of data that is not yours.
  • There is no bug bounty programme and no payment. Said up front, because finding it out after the work is worse than knowing before it.
  • Commercial and procurement questions go elsewhere — sales@infro.io for a security review or a questionnaire, support@infro.io for an account you already hold.