Security

Agents behave differently from users and from applications. They make a lot of decisions quickly. They read input written by people you don't necessarily trust (suppliers, vendors, attachments, the broader internet). And they can be talked into actions outside their original scope by anything they read.

The security stack most teams already have was built for software that does one thing at a time on behalf of one person who clicked a button. It doesn't cover the way agents fail. The controls below are what we built into the foundation so the failure modes specific to agents are caught early.

A short list of attack patterns that shaped how the architecture was put together. The ones below are the ones we considered first-class during design and that we test against on every release.

Every action an agent takes runs under the identity of the person who asked for it. If the user can't read pricing data, the agent can't either. Whatever access rules your systems enforce, those are the rules in effect when the agent acts.

When agent A invokes agent B on the user's behalf, B also runs as the user. Agents never inherit each other's authority. This is the control that closes the most common version of the confused-deputy attack.

We don't operate a privileged service account. Every downstream call carries a fresh credential scoped to the requesting user, signed by our HSM, with a 60-second lifetime.

Agents are defined declaratively. Each definition lists the tools the agent can use, the value thresholds above which a human has to approve, and the rate limits that bound how fast the agent can move. Definitions live in version control. Promoting one to production goes through the same review as any other production change.

The runtime enforces these definitions. An agent can't call a tool that isn't on its allowlist. Repeated actions with identical arguments break after three cycles. High-impact actions pause for human approval, and the full decision context is logged when they resume.

Every call an agent makes to a system goes through one place. The gateway terminates the agent's connection, checks the call against the agent's allowlist, issues a fresh credential scoped to the user, and forwards. Responses come back through the same path and get validated against an output schema before they reach the agent.

The gateway is per tenant. There's no shared compute pool that processes more than one customer's traffic. Cross-tenant access isn't possible because the cryptographic keys that would decrypt another tenant's traffic live in a separate KMS partition under a different IAM policy.

Each agent has a behavioral baseline that updates continuously. We track how often it calls each tool, what its arguments tend to look like, what its outputs look like, what time of day it usually runs. When current behavior drifts in ways that match a known attack pattern, the agent is quarantined and a human is paged.

The signals and thresholds are visible to your security team and tuned per tenant. They're what our on-call team operates against day to day.

Every action an agent takes gets written to the audit log: the action, the agent, the user it ran for, the arguments, the result. The log is append-only at the database level. The database role that writes to the log can insert and read; it can't update or delete. Changing that grant requires two engineers to approve.

Each row is signed by an HSM at write time and chained to the hash of the previous row, so any tampering breaks the chain in a way that can be verified from outside the system. The chain is checked continuously by our own infrastructure and re-verified quarterly by a third-party auditor.

We hire an external firm to test the full Spaceflow surface every quarter. Findings flow into our standard issue tracker with internal SLAs of 7 days for critical, 30 for high, 90 for medium. We share the current state with customers who ask.

Between external tests, a small internal team runs continuous adversarial exercises against staging. Things like replaying known prompt-injection payloads, fuzzing tool arguments, and simulating token replay. Anything that crosses from staging into a production path gets treated as a production finding.

If you're on a security or compliance team and you need more detail than this page provides, the easiest path is to book a call. We'll walk through whatever's relevant for your review and follow up with reports under NDA where appropriate.