Infrastructure security

Why this is a security page, not just an ops page

If a request has to pass through infrastructure we don't ourselves control, that changes what our commitments actually mean. Every privacy and safety commitment described anywhere on this site is, in the end, only as strong as a contract with whoever operates that infrastructure on our behalf. That's a real, structural limit on how strong any commitment can actually be. It doesn't matter how carefully the commitment itself is worded. A promise is only as good as the party's ability to actually enforce and verify it. A party relying on someone else's infrastructure has limited ability to verify claims about that infrastructure independently.

tAI runs end to end on servers we operate ourselves, specifically to close that gap. The entire path a request travels is infrastructure we control. That's true from hitting our servers to a response reaching you. It's infrastructure we can actually audit, actually change, and actually take direct responsibility for. It isn't something we're trusting a third-party vendor's status page and a signed contract about. We think that distinction is the difference between a security commitment that's genuinely load-bearing and one that only sounds that way on a marketing page. Being able to actually verify a claim ourselves is different from having to trust someone else's word about it.

Topology

tAI runs across multiple data centers, rather than a single machine or a single location. That way, a hardware failure or a network outage affecting one specific location doesn't take the entire product down for every user at once. Each node in that topology runs a full, complete copy of the application stack. It's genuinely capable of serving real production traffic entirely on its own. It doesn't sit idle as a passive standby that would need to be manually promoted and brought up to speed before it could actually handle anything. That design meaningfully shortens how long any real failover actually takes in practice.

The database holding chats, connector state, and account data sits behind streaming replication to a hot standby. A primary database failure has an already-current copy ready to take over immediately. It doesn't require a slow, manual restore from a backup taken at some earlier point in time. A backup restore would mean losing whatever changed between that backup and the moment of failure. We built and thoroughly tested this failover path ourselves. We didn't rely on a vendor's documentation about how their equivalent system is supposed to behave. That included deliberately taking the primary offline under controlled conditions, specifically to confirm the standby actually takes over correctly under real conditions, not just in a design document.

Tested failover, not just designed failover

A failover path is only as trustworthy as the times it's actually been triggered for real under genuine, controlled conditions. A system that looks correct on paper but has never actually been exercised carries a real, unquantified risk. It might not behave the way the design document claims, once something actually goes wrong. We run live drills that intentionally take the primary application and database offline under controlled circumstances. We confirm that traffic correctly moves to a standby node. We separately confirm that it moves back cleanly once the primary recovers, rather than treating a clean recovery as something that would presumably just work itself out.

A failover system that's only ever been reviewed on paper is treated as fundamentally unproven here. That's true regardless of how well-reasoned the design behind it looks. This is why it's tested deliberately and on a periodic, repeated basis. It isn't validated once at initial launch and then never revisited again. The system around it continues to change and evolve. Infrastructure that worked correctly a year ago isn't guaranteed to still work correctly today, after unrelated changes have been made elsewhere in the stack. Periodic re-testing is how that assumption gets checked, rather than quietly taken for granted indefinitely.

The honest trade-off

Running your own infrastructure means capacity planning is our direct problem to solve ourselves. So is on-call incident response, and every operational failure mode that can occur. It's not a support ticket filed with a cloud provider, followed by a wait for their team to investigate on their own timeline. That's a genuinely real cost. It shows up in engineering time, operational attention, and organizational focus. It isn't a hidden or minimized cost we'd rather not mention. Pretending otherwise would undercut the credibility of every other claim on this page.

We think that trade-off is the correct one for a product that people connect their email, their code, and their real work to. Real operational cost, in exchange for infrastructure we can actually verify and change ourselves, is worth paying. But it is a genuine trade-off with real downsides, not a free upgrade with no cost attached. The fuller account of this decision is at ai.artfical.com/about/infrastructure. That includes the specific isolated sandbox environment tool execution runs inside. It's written from more of an operational and company-philosophy angle. The sandbox itself is covered specifically in security terms on the Sandboxing page linked earlier in this section.

Keeping the software itself current

Infrastructure security isn't only about topology and failover, covered above. It's also about whether the software actually running on that infrastructure, operating systems, database engines, and every dependency the application stack pulls in, stays patched against known vulnerabilities as they're disclosed. Owning our own infrastructure, described above, means that patching schedule is entirely our own responsibility rather than something we're waiting on a cloud vendor to handle on their own timeline. That's a real, recurring operational commitment, not a one-time setup task completed once at launch and left alone. It's also the same trade-off described above, in a different form: we could rely on a vendor's own patching cadence and lose the ability to verify or accelerate it ourselves. We think owning that responsibility directly is worth the extra operational load it creates.

A security patch to core infrastructure goes through the same staged, tested rollout discipline described above for the application itself, rather than being pushed directly to every node at once. That's true even for something as routine-sounding as a dependency update, since a routine-sounding change is exactly the kind that occasionally has an unexpected interaction with the rest of the stack. Treating infrastructure patching with the same care as an application release, rather than as a separate, lower-scrutiny category of change, is part of the same underlying philosophy that runs through the rest of this page: verified and tested, not just designed and assumed to work. A patch applied everywhere at once, with no staged verification, would recreate exactly the kind of unproven, paper-only confidence the tested-failover section above argues against. We hold infrastructure changes to the same bar, rather than treating security patching as too urgent to slow down for. Urgency is a reason to prioritize a patch, not a reason to skip verifying it actually works as intended before it reaches every node.