Ident.ink is publishing its clearest operating record yet: the controls around requests, accounts, releases, recovery and incident handling, plus the limits we will not hide behind marketing.
The boundary starts before application logic
Public requests pass through bounded input handling, method and framing checks, abuse controls and service-specific rate limits. Authenticated actions are authorised again on the server. Customer-supplied connections use explicit allowlists and constrained network access; they are not treated as shell commands and cannot become a route for downloading or executing code.
Sessions use protected cookies and server-side validation. Sensitive account and administrative paths add further verification, and supported accounts can use passkeys and multiple authentication factors. Secrets remain server-side and are excluded from public diagnostics, release evidence and recovery bundles.
Data and recovery are separate concerns
Ident.ink keeps its core account and project store private, with no public database listener. Database access is mediated by services, privileged actions are audited and backups are encrypted and integrity checked. Service isolation is intended to keep one component failure from becoming a platform-wide failure. It reduces blast radius; it does not make failure impossible.
Production candidates are built away from the live release. Reviews cover source safety, syntax, product claims, tests, dependency health, database integrity, production builds, routes, headers and a timed stability soak. Activation uses a verified backup and retains an immutable prior build for rollback. A compile alone is never described as proof of functionality.
What happens when an error occurs
Customers receive a bounded message or reference rather than a stack trace, credential, database detail or internal path. Health probes, structured security events, audit actions and request references provide the internal evidence used to reproduce and isolate a fault. Confirmed customer impact belongs on Status; material operating changes belong in News and the Transparency ledger.
Response is risk-led, not marketing-led. A credible active threat or data-loss risk is contained first. A service fault is confirmed, scoped, repaired and verified before it is described as resolved. Ident.ink does not publish a blanket guaranteed response or resolution time. A guaranteed time applies only where it is written into the customer's contract. Support priority, investigation order and a repair estimate are not the same as a contractual SLA.
Controls have limits
No internet service can promise absolute security, uninterrupted availability or protection from every attack. Encryption does not protect a compromised endpoint. Rate limiting does not replace authorisation. Backups do not replace restoration testing. Automated detection does not replace human judgement for legal, billing, moderation or serious security decisions.
That is the point of this record: customers, staff, partners and reviewers should be able to distinguish an implemented control, a measured event, a contractual commitment and an honest limitation.