The boundaries, as built.
Friday runs software agents with real access to real systems, so this page does not ask you to trust us. It tells you how the system is arranged, what each layer is for, and what each layer cannot do alone. The limits are stated as plainly as the controls, because a security page that cannot name its own limits is marketing.
AS OF 4 AUGUST 2026 · PRIVATE PREVIEW
The threat we design for
An agent with real access can be manipulated. Text it reads on your behalf can try to become instructions, and a persuaded agent uses exactly the access you granted it. We treat this as a fact of the medium, not an edge case.
So the architecture is arranged around one question: when an agent is manipulated, what can it actually reach, steal, or spend? Every layer below exists to make that answer smaller.
Where your agents run
Every task runs in a sandboxed container on gVisor, a syscall-intercepting isolation layer originally built at Google. One tenant per process, never shared. Execution environments are ephemeral by construction: the process that ran your task is not reused for anyone else's.
Durable state lives in per-tenant storage, mounted read-only wherever the task does not need to write. Configuration lives off the tenant-writable surface, so a compromised task cannot rewrite its own rules and persist.
The credential rule
The process that runs your agent holds no credentials. No provider API keys, no database access, no webhook secrets. There is nothing in its environment worth stealing, which is the only reliable answer to key theft.
Work arrives with a signed, per-task grant minted upstream: scoped to one task, one tenant, one budget, with an expiry. The tier separation is pinned by tests in our build, not by convention. A change that hands a fleet credential to an executor fails our test suite before it can deploy.
Egress goes through the broker
Agent processes have their network closed by default. What opens, opens through our broker: every outbound call is a typed, schema-validated request, authorized against your policies, budgeted, and logged. An agent never gets a raw socket to the internet and a shell string.
The honest limit: an agent authorized to reach a channel can misuse that channel. Brokering narrows what an attack can do and records what it did. It does not make an authorized action safe by itself. That is what approvals are for.
Budgets are a security boundary
Every plan includes a monthly dispatch wallet, and the wallet is a hard rail in the runtime, not a billing preference. A runaway or hijacked agent runs out of budget; it does not run into your card. There is no overage: the lane slows, the bill does not.
Every run is priced by a versioned price book before it executes and receipted after, line by line, in the console. Cost anomalies are visible the day they happen because cost is a first-class record, not an end-of-month surprise.
Approvals, scopes, and the asks queue
Access is granted in scopes, and the narrow ones are the default: read, then draft, then send. Consequential actions are designed to queue for a human with the agent's reasoning attached. Nothing goes out while an ask is waiting.
Our terms say this plainly and we repeat it here: holding consequential actions is a design posture, not a guarantee. AI systems make mistakes, including confident ones. Do not point an agent at something irreversible and stop reading.
Prompt injection, stated honestly
Untrusted content is wrapped and role-separated before the model reads it, so a paragraph in an email is harder to mistake for an instruction from you. Instruction-bearing files are treated as tainted input, not trusted state.
This is a mitigation, not a boundary, and we will not describe it as one. The layers that hold when persuasion works are the ones above: no credentials to steal, brokered egress, budget caps, and approvals on anything consequential. Behavioral signals, like bursts of denied egress or abnormal tool loops, exist to catch what the design did not model.
Your data
Sign-in is Google only. We do not issue or store passwords.
Application data is readable and writable only by our server-side services; client applications get no direct database access, and the database default-denies anything we did not explicitly wire. Payment is handled by Stripe, and card numbers never touch our systems. Billing webhooks are signature-verified and processed exactly once.
What we do not have yet
Friday is in private preview, and this list is the work in front of us rather than fine print.
- No SOC 2 or ISO certification yet. The certification workstream is scheduled ahead of enterprise availability, and this page is the architecture it will audit.
- No uptime SLA on standard plans. Enterprise agreements carry one.
- No published third-party penetration test yet.
- Chat-surface integrations beyond the core are still rolling out, and we list what is connected rather than what is planned.
Bring your security team.
A read-only pilot is not a concession we make; it is how the product is designed to start. Scopes begin at read, approvals sit on anything consequential, and every run leaves a receipt. For the architecture conversation, the questionnaire, or anything this page left you wanting, write to support@forerunner.ai.
How we handle what we collect is its own document: the privacy policy. What we promise and what we do not: the terms.