Agent Safety Controls
Last reviewed: August 14, 2026
Meta Council runs autonomous agents that read data, call tools, spend money and write to systems of record. So the question a security reviewer should ask us is not only "is the data encrypted" — it is "what are these agents actually prevented from doing, and what enforces it?"
This page answers that control by control. For each one it states the limit, how the limit is enforced, and — deliberately — where the limit stops. Every control described here was verified present in the running codebase at the time of writing by locating the check that gates the operation. Where we looked for a gate and found only a convention, this page says so instead of claiming the control.
How to read this page. A control we enforce is stated plainly. A control we do not enforce is named in What we do not have rather than omitted. We would rather lose a deal on a gap we disclosed than win one on a claim that fails your penetration test. The same standard governs Trust & Security: we hold no third-party security certification today and do not describe ourselves as holding one.
1. A credential can only do the things it was issued to do
Every programmatic credential is stored only as a one-way digest. We keep no copy of the key itself, which means we cannot show it to you again after issue, cannot recover it, and cannot leak it from our database in usable form. Lookup happens by digest, never by key material. A credential past its expiry is deactivated on the request that discovers it, and deactivated credentials are excluded from lookup entirely.
Each credential carries an explicit list of permitted operations, and that list is checked on every single request — both for our tool-calling interface and for the REST API, on separate enforcement paths. This is what makes the boundary real rather than advisory: a credential issued to read the ticket board cannot send outreach, because sending outreach requires a permission that credential was never granted and that no default or legacy grant includes.
Three properties of this system are worth a reviewer's attention, because they are the ones that usually turn out to be missing elsewhere:
| Property | What it prevents |
|---|---|
| New endpoints fail closed | When an engineer adds an API route and has not yet classified which permission it requires, the system does not treat it as unrestricted. It requires a permission that no credential can hold, so an unclassified route is refused to every scoped credential rather than being silently open. The common version of this bug — a new endpoint defaulting to public — cannot occur here. |
| Revoking a credential revokes everything derived from it | Where a credential has been used to issue a narrower child credential, every authenticated request re-checks the parent. Revoking or expiring the parent immediately kills all of its descendants. A delegated credential cannot outlive the credential that created it, and delegation cannot widen permissions — a child can only ever receive a subset of what its parent holds. |
| The system reports when a grant is broader than it looks | Two situations make a credential more powerful than its stored permission list suggests: an empty list falling back to a legacy grant, and a credential deliberately issued with full access. When you ask what a credential can do, the answer names which of these applies rather than printing a tidy list that understates it. |
Where this control stops. A credential can be deliberately issued with full access, and such a credential satisfies every permission check — that is what it is for, and it is a choice made at issue time, not a bypass. Scope fencing applies to programmatic API credentials; a session authenticated by other means is governed by that mechanism instead. A small number of self-directed operations — asking what your own credential can do, and replacing your own credential — are deliberately unscoped, because they grant no authority the caller does not already hold, and scoping the replacement operation would strand the exact credential most in need of rotation.
2. Spend has a ceiling that is checked before work starts
An autonomous agent that loops is a financial risk, not just an operational one. Platform-funded model spend is capped by a monthly ceiling, per user, set per pricing tier. The ceiling is checked before work begins, on each of the paths that can start paid work: expert panel runs, workflow runs, the API, the outreach paths, and the scheduler that starts work with no human present. A user over the ceiling is refused up front rather than discovering the overage on an invoice.
Two scoping facts matter more than the number:
- It is a monthly per-user ceiling, not a per-run ceiling. We describe it that way deliberately. A single run is bounded by the remaining monthly headroom, not by a separate per-run limit.
- Spend on your own provider key is never metered against it. If you bring your own model credentials, that is your own money and your own provider's limits. The ceiling governs spend that we fund.
Work performed inside a workflow feeds the same ledger the ceiling reads — including work started by the scheduler with no human present. Attribution of a step to platform-funded or customer-funded spend is taken from the credential the step actually ran on, not from whether the customer happens to have a provider key stored. That distinction is what stops a user with any stored key from running unlimited platform-funded work.
Where this control stops. The spend ledger is held per serving process. Running more than one server process means each one meters only the requests it handled, so a determined user could exceed the ceiling by roughly the number of processes before the ceiling binds. Recording spend is also best-effort by design — a metering failure must never take down a customer's workflow — so the ledger is a floor on spend rather than an exact figure. Treat the ceiling as a blast-radius control, which is what it is, and not as a billing guarantee. Unauthenticated usage is covered by a separate global budget rather than by the per-user ceiling. We publish the mechanism rather than the dollar amounts, because the amounts are configurable per deployment and a published number could silently stop being true.
3. A person can be required before an agent continues
A workflow can pause at a checkpoint and refuse to proceed until a human approves or rejects the work so far. Rejecting discards the step's output and re-runs it rather than passing it downstream.
Approving is a separately granted permission. It is not implied by the ability to read a workflow or to start one, and a default-issued credential does not carry it. An agent that can run workflows therefore cannot approve its own checkpoints unless someone deliberately granted it that permission.
A checkpoint belongs to the person whose workflow it is. An authenticated request from a different account is answered as though the session did not exist, rather than as a permission error — so a third party cannot map which sessions exist by watching which ones refuse them differently.
Separately, escalations that need a human decision are routed into the platform's own ticket system, so the decision leaves a durable record instead of living in a chat log.
Where this control stops. Checkpoint state is held in the serving process, so a deployment running multiple server processes can route an approval to a process that does not hold that session. Treat multi-process checkpoint routing as unfinished. And the approval surface today asks a human to approve a step — it does not yet render the specific action being authorized in full. Approving is therefore a meaningful gate on whether work continues, and not yet a complete disclosure of what is being authorized. That gap is tracked and named below.
4. The safety reviewer is a required participant where it is seated
Some panels seat a dedicated safety reviewer persona. Where a panel seats one, it is a required participant, and that requirement is enforced in three independent places:
- The panel definitions declare it required, in version-controlled files where a change leaves a reviewable diff.
- An automated test asserts that every panel seating a safety reviewer marks it required, and that it has not been removed from the product entirely. Demoting it in one panel, or quietly deleting it everywhere, fails the build.
- A required participant's failure blocks synthesis. The system refuses to produce a final answer built on a panel whose required member did not report. A customer's own saved customizations can change many things about an agent, but they cannot make a required participant optional.
Where this control stops — stated precisely, because it is easy to overclaim. The safety reviewer is not seated on every panel, and this is deliberate rather than an oversight: the default fast panel is a small three-agent council, and other panels are domain-shaped. Its numeric influence weight is calibration, not a gate — different panels intentionally run it at different weights relative to their own scale, and a customer's saved customization can change that weight for their own runs. We therefore do not claim its weight cannot be lowered. What we claim, and what the code enforces, is that where the reviewer is seated it is required, and that a required participant's failure stops the answer.
5. Labels describe work; they do not authorize it
Our agents operate a ticketing system, which raises an obvious question: can an agent grant itself authority by labelling something? Authority in that system does not live in labels. It lives in structured fields, each with its own check — and those checks are pinned by automated tests. A work item requires at least one live qualifying scenario before it can be considered ready; a dependency that is not itself finished blocks it; stale or non-qualifying results are rejected rather than counted; and readiness is computed deterministically, so it cannot vary between two callers asking the same question. An unrecognised work-item type fails closed rather than defaulting to permitted.
Where this control stops. This is a documented and reviewed design property, not an enforced impossibility. Nothing rejects a label merely because it reads as though it confers authority — what the system guarantees is that the authority checks do not consult labels when deciding. We state it that way rather than as a blanket prohibition, because the blanket version is the kind of claim that fails the first time somebody tests it.
What we do not have
This list is part of the document, not an appendix to it. A control absent here is absent from the product.
- Workspace-level role-based access control. Open and unstarted. Access control today is per-account and per-credential, not per-workspace-role.
- Per-action approval that renders the concrete action. Open and unstarted. As described in section 3, a human approves a step rather than a fully rendered description of the action being authorized.
- Single-process state for spend metering and checkpoint routing. Both controls are correct within one serving process and degrade across several, as described in sections 2 and 3.
- Automatic capture of agent failures for analysis is built but switched off in production. We do not claim it as an operating control.
- Test coverage of one enforcement point. The rule that a customer's saved customization cannot make a required participant optional is enforced in code but is not currently pinned by its own test. We are naming it because an unpinned rule is one refactor away from being an unnoticed regression.
- No third-party security certification. We hold none today and do not describe ourselves as holding one. See Trust & Security for the current status and what is underway.
Verifying this yourself
Every claim above was traced to the specific check that gates the operation, recorded internally with file and line at a fixed commit. If you are evaluating us and want a control walked through against the source, ask and we will do it against the code rather than against this page. The companion documents are Trust & Security for data handling and the full gap list, and Enterprise for deployment and commercial terms.