Security
Roster runs on AWS with per-employee isolation and per-agent scoping as load-bearing properties of the architecture, not bolted on. This page is the IT review of the platform — forward it to whoever asks.
The four properties
Every employee's agents run in their own AWS Fargate task. Each agent gets its own EFS access point. Each user has their own KMS key scope. There is no admin-view-across-users path in the production control plane — that's enforced in code, not policy.
Roster does not resell tokens or store your provider OAuth credentials in plaintext. You bring your Claude, ChatGPT, or Gemini subscription. Tokens are KMS-enveloped at rest, read into runtime memory on task start, and never appear in CloudWatch, DynamoDB plaintext, or any operator-visible surface.
Skills (what an agent knows how to do) and connections (what an agent can reach) are picked per agent, not per user. The AE's agent has the CRM. Finance's agent has the bank feed. Neither sees the other's tools, even though both belong to the same employee's account.
Every agent action — tool call, message sent, file written — produces a structured log line tied to a request ID, user ID, and agent ID. The control-plane history is the source of truth for what an agent did, not the chat transcript.
The architecture, in a table
| Layer | What runs there | Isolation boundary |
|---|---|---|
| Runtime | Per-(user, agent) ECS Fargate task running the provider CLI and your selected skills. | Compute boundary. Read-only root, dropped caps, no cross-task network. |
| Persistent state | Agent memory, skill files, work products. | Per-(user, agent) EFS access point. |
| Credentials | Your provider OAuth tokens, third-party connector tokens. | AWS Secrets Manager, KMS-enveloped, per-user key scope. |
| Control plane | User accounts, agent definitions, audit logs. | DynamoDB rows keyed by user_id and agent_id. No tenant-wide query path. |
| Channel relay | WebSocket message broker between your devices and your runtimes. | Per-connection HMAC. Never trusts a user_id sourced from the runtime side. |
What we don't do
Roster does not use customer data to train models. We don't have our own model to train. Your provider's terms govern whether their model trains on your data — for Claude, ChatGPT Team, and Gemini Enterprise the default is no.
Your provider subscription is your bill. We don't mark up inference. We don't have a hidden token meter. The platform fee is the platform fee.
Operators cannot read employees' agent state, conversations, or outputs from production. Debugging works through structured logs (no message bodies), customer-initiated diagnostics, and replay tooling that requires explicit consent.
Platform email — account notices, billing, lifecycle — comes from a Roster sender on AWS SES. Your Google Workspace or M365 connection is only used for delegated work the employee initiated.
For the IT review
If your IT or security team needs a SIG, sub-processor list, or a deeper architecture walkthrough before you roll Roster out, email security@rosterai.app. We'll send the documents back within two business days.