# INFRO — security questionnaire responses Last checked against the codebase: 26 September 2026. Canonical version: https://infro.io/security-questionnaire.md Published alongside: https://infro.io/trust This document answers the questions a security review asks, including the ones where the answer is no. It is generated from the same source as the Trust Center page, so the two cannot disagree. Where a statement is a policy rather than a mechanism, it says so; where a control does not exist, it is listed under Known gaps rather than omitted. Send anything this does not answer to sales@infro.io. Vulnerability reports go to security@infro.io. ------------------------------------------------------------------------ ## Summary for a reviewer in a hurry - INFRO is an AI gateway and control plane. Your applications call us; we call the provider accounts you connected, with your credentials. - We hold **no SOC 2 and no ISO 27001** today, and claim neither. An audit firm is engaged for SOC 2; no observation window is scheduled and no date is published. The roadmap is below. - **No independent penetration test** has been performed. Our security review is an internal self-assessment. - Prompt and completion capture is **off by default**, with a retention window you choose and a deletion sweep that runs. - Provider credentials are sealed with AES-256-GCM, bound to your tenant, and **never returned by any interface**, including ours. - The audit log is **append-only, enforced by the database**, not by application code. - There is **no region-constrained processing**. The hosted service is **multi-tenant**, with logical isolation; a **self-hosted or hybrid deployment** is available only on an enterprise agreement, scoped per contract. SAML/OIDC SSO and SCIM 2.0 provisioning are included from the Business plan and are new: we configure the first connection with each customer. ------------------------------------------------------------------------ ## Compliance roadmap 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. ### SOC 2 Type I - Audit firm engaged: **yes** - Observation begins: **not yet published** - Report expected: **not yet published** 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. 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 - Audit firm engaged: **yes** - Observation window begins: **not yet published** - Observation window ends: **not yet published** - Report expected: **not yet published** An auditor's opinion that those controls operated effectively across an observation window, which is the report most security reviews actually want. 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 - Audit firm engaged: **no** - No milestone dates committed. 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. ------------------------------------------------------------------------ ## Controls in place Each control names the mechanism that enforces it, so that your engineer knows what to probe rather than what to take on trust. ### 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:: for inference credentials, and billing:: 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=,v1=, 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. ------------------------------------------------------------------------ ## Company and product **Q. What does the product do with our data?** A. INFRO is an AI gateway and control plane. Your applications call INFRO; INFRO calls the AI provider accounts you connected, using your credentials, and returns the response. We record metadata about each request for metering, cost estimation and governance. We record request and response content only if your organization turns capture on. **Q. Who are the AI providers, and are they your subprocessors?** A. They are providers you selected and contract with directly, under your own agreements. They are not INFRO subprocessors — the request runs on your account, and the provider bills you, not us. INFRO's own vendors are listed at https://infro.io/subprocessors. **Q. Is the service generally available?** A. It is in private early access. The gateway and both consoles are deployed and running. Self-serve sign-up and general key issuance are not open to everyone yet. See https://infro.io/trust for what that means for a security review. **Q. What is the corporate entity?** A. Stated in full, including the operating entity and jurisdiction, at https://infro.io/terms. We will not describe it differently to get through a review. ------------------------------------------------------------------------ ## Data handling and retention **Q. Do you train on customer data?** A. No. INFRO does not train on, or sell, customer prompts, inputs or outputs. Your connected providers' handling of your data is governed by your agreements and account settings with them. **Q. Is prompt and completion content stored?** A. Not by default. The database column controlling capture defaults to off and there is no plan on which it defaults to on. When an organization enables it, content is stored separately from metering records with a per-organization retention window. **Q. Can INFRO inspect or filter prompt and response content?** A. On chat completions, yes, if you turn guardrails on (Business plan and above). They are deterministic patterns that run inside the gateway and call no outside service: email addresses, phone numbers, card numbers (issuer prefix and Luhn), IBANs (mod-97), US Social Security numbers, IP addresses, common API key and private key formats, and a list of terms you supply. Each rule blocks, redacts or flags. They are not classifiers: they do not detect prompt injection, jailbreaks or toxicity, they do not inspect images, audio or other endpoints, and they can miss data outside the listed formats. Matched text is never stored; only counts per detector are recorded. Nothing is turned on for a new organization. **Q. What retention windows are available, and is deletion actually performed?** A. 24 hours, 14, 30, 60 or 90 days, or one year, capped by the plan's ceiling — what is stored is the shorter of the two. A scheduled job deletes expired payloads in bounded batches, and its lag is monitored. Deletion is a DELETE, not a flag. **Q. How do we get our data out, or have it deleted?** A. Usage and request records are available through the API on any gateway key, so you can export on your own schedule. For deletion, contact support; the DPA at https://infro.io/dpa sets out the obligations we are bound by. **Q. Where is data processed?** A. The database runs in Frankfurt (eu-central-1), and the gateway runs in Cloudflare’s Frankfurt location beside it. Requests enter Cloudflare’s network at the location nearest the caller, where TLS terminates. Each request’s total time and the provider’s own time are shown side by side in the console, so the overhead is measured rather than asserted. We do not offer region-constrained processing and do not claim to. ------------------------------------------------------------------------ ## Encryption and key management **Q. Is data encrypted in transit?** A. Yes. TLS on every hostname, with HSTS set and HTTP upgraded. The OpenTelemetry collector endpoint you configure is constrained to HTTPS by a database constraint, so a plaintext endpoint cannot be saved. **Q. Is data encrypted at rest?** A. Provider credentials are sealed with AES-256-GCM under a key held outside the database, with your organization and connection identifiers bound in as additional authenticated data. The managed database and object storage encrypt at rest under their own vendor controls. **Q. How are our provider API keys protected?** A. Sealed as above; never returned by any interface, including our internal operator console; and unusable if moved to another row or tenant, because the binding fails closed. What either side sees after saving is the last four characters. **Q. How are INFRO API keys stored?** A. As a SHA-256 digest of 32 cryptographically random bytes, with a display prefix and last four characters. A database disclosure does not yield a usable credential. Revocation writes a tombstone so it cannot be undone by a stale cache entry. **Q. Can encryption keys be rotated?** A. Yes. Rotation re-seals every stored credential in place without customer involvement, and the stored algorithm carries a version string so schemes can coexist. ------------------------------------------------------------------------ ## Identity and access management **Q. How is access to the production environment controlled?** A. The internal operator console is a separate application on a separate hostname, behind two independent gates: an edge gate that authorizes serving the application at all, and a session check on every individual request. Operator accounts are provisioned, never self-registered, and are an explicit allowlist. **Q. Is multi-factor authentication enforced for staff?** A. TOTP two-factor is available and is off by default — a decision we state rather than imply. Independently of it, actions that move money, change credentials or alter another operator's access require a second factor presented within the last 15 minutes; where two-factor is off that step-up is the password. Ten consecutive failures lock the account. **Q. Can we require MFA for our own users?** A. Yes, on every plan. An owner or admin turns on "Require two-factor authentication" for the organization; members without it are asked to set it up before they can use that organization, and the members list shows who has it on. Methods are an authenticator app with recovery codes, and passkeys or hardware security keys. Members who sign in through your SAML or OIDC single sign-on satisfy it through your identity provider. **Q. Can staff read customer prompts?** A. The operator console reports whether a payload was retained. It does not return payload content. **Q. What access controls exist for our own users?** A. Four organization roles — owner, admin, developer, analyst — with console access and key scope per role, projects, per-project model allowlists, and budgets at organization, project, member and key level. SAML/OIDC SSO and SCIM provisioning are included from the Business plan. **Q. Are administrative actions logged?** A. Yes, to an append-only log enforced by a database trigger: UPDATE, DELETE and TRUNCATE are rejected by the database, not by application code. Every row carries an actor and a timestamp, and it is visible to you in the console. ------------------------------------------------------------------------ ## Application and infrastructure security **Q. What browser security headers are set?** A. Content-Security-Policy, Strict-Transport-Security, X-Content-Type-Options, X-Frame-Options: DENY, Referrer-Policy, Permissions-Policy and Cross-Origin-Opener-Policy, on the marketing site, the customer console and the operator console. Verifiable with curl -I. **Q. How is tenant isolation implemented?** A. Logically. Every console endpoint derives the organization from the authenticated session and passes it explicitly, so it cannot be read from request input. Sealed credentials are cryptographically bound to their tenant. A structural test asserts that internal identifiers and upstream error bodies never reach a customer response. **Q. Are webhooks authenticated?** A. Outbound webhooks carry an HMAC-SHA256 signature over the timestamp and raw body, with dual signing during secret rotation. Inbound payment webhooks are verified before anything in them is read, and entitlements change only on a verified delivery — never on a redirect. **Q. How do you protect against abuse of unauthenticated endpoints?** A. There are two, both outside the authenticated API and on separate routers. Both are size-limited, rate-limited by network address and constrained at the database. Request bodies everywhere are size-limited before parsing, with a documented error rather than a timeout. **Q. Do you have a WAF and DDoS protection?** A. The platform runs behind Cloudflare, which provides network-layer DDoS protection. Application rate limiting is implemented in the gateway and counted at the location where the gateway runs rather than by one global counter. ------------------------------------------------------------------------ ## Monitoring and operations **Q. Do you have monitoring and alerting?** A. Yes. Scheduled tasks record every run; failures, stalled tasks, error-rate spikes, payload-purge lag and webhook backlog raise operator alerts. Authentication events are recorded, including failures, in a table separate from the audit log and with a bounded retention window. **Q. Do you have documented incident response?** A. Yes — written runbooks for a leaked key, a provider outage, a bad deploy and metering recovery, each opening with the first action to take. They are internal documents; we will walk through them on a call. **Q. What is your backup and recovery position?** A. The database is a managed service with its vendor's point-in-time recovery. Separately, a scripted dump-and-restore drill runs against a disposable database: it simulates total loss, restores, re-verifies the schema and compares row-level checksums table by table. Stated precisely, because the distinction matters to you: that drill measures our own procedure and tooling, not the managed service's point-in-time restore, which is a different mechanism with its own timings. There is no published RTO or RPO on self-serve plans, and we will not quote one we have not measured. **Q. Will you notify us of a breach?** A. Yes, without undue delay. The obligation is set out in the DPA at https://infro.io/dpa, which is the enforceable statement of it rather than this document. **Q. Is there a status page?** A. https://infro.io/status runs a live check against the gateway from your own browser. It publishes no historical uptime percentage, because we do not yet measure one from outside our own infrastructure and a number we cannot stand behind is worse than none. ------------------------------------------------------------------------ ## Compliance and legal **Q. Do you hold SOC 2 or ISO 27001?** A. No. Neither is held today. An audit firm is engaged for SOC 2; the observation window is not yet scheduled, and the roadmap at https://infro.io/trust is where its dates will be published when it is — there, rather than sent to individual reviewers, so that everyone holds us to the same commitment. ISO 27001 is under evaluation with no auditor engaged and no date committed. **Q. Will you sign a DPA?** A. Yes. It is published in full at https://infro.io/dpa, incorporating the Standard Contractual Clauses with the UK Addendum. Execution is by email; there is no console countersigning flow, and we say so rather than implying a button. **Q. Has an independent penetration test been performed?** A. No. Our security review is an internal self-assessment and we describe it as one. **Q. Does using INFRO make us GDPR or EU AI Act compliant?** A. No. INFRO records the model, provider and route for each request, which supports your own reviews. It does not classify your application, label generated content, or establish compliance on your behalf. ------------------------------------------------------------------------ ## Posture summary - **No training on your data** — Committed. 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 default** — Committed. 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 rest** — Committed. 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 log** — Committed. 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 list** — Committed. 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 27001** — Not 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 Clauses** — Committed. 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 residency** — Not 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. ------------------------------------------------------------------------ ## Known gaps Listed here because a security document with no gaps is a document a reviewer discounts entirely, including the parts that are true. - **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. ------------------------------------------------------------------------ ## Contacts and documents - Security review and questionnaires: sales@infro.io - Vulnerability reports: security@infro.io - An account you already hold: support@infro.io - Trust Center: https://infro.io/trust - Data processing agreement: https://infro.io/dpa - Subprocessors: https://infro.io/subprocessors - Privacy policy: https://infro.io/privacy - Acceptable use policy: https://infro.io/acceptable-use - Terms of service: https://infro.io/terms - Error taxonomy: https://infro.io/docs/api/errors - Gateway status: https://infro.io/status