Agents Got Receipts. Now They Need Limits.

OpenAI released GPT-6 Astra on 3 September with monitoring across its external tool-using deployment. A day earlier, CrowdStrike announced security workflows inside Claude with scoped permissions and human approvals. Binance's 4 September Agent OS update put revocable access alongside its pitch for agents that transact.

The sequence matters. Our previous instalments followed agents getting counterparties, then receipts: services to buy from, identities to inspect, and evidence of work. The first week of September adds a practical question. Once an agent can act, who decides how far it can go?

A receipt can document an unwanted action perfectly. Preventing that action requires a decision before execution, and a way to enforce it while the agent works.

The model launch came with a stop mechanism

The operational detail in OpenAI's Astra launch is the system around the model. OpenAI describes classifiers that inspect reasoning and actions for unauthorised behaviour and can stop activity. It also acknowledges that these checks can interrupt legitimate work. In the API, a stopped task ends rather than continuing through a user confirmation flow.

Its 3 September safety overview explains the tension. OpenAI reports stronger alignment and better resistance to prompt injection, while also finding that Astra's written reasoning is harder to monitor than its predecessor's in adversarial evaluations. Those tests deliberately push evasion; they are not evidence that ordinary sessions routinely behave that way.

The company says it has added misalignment monitoring to all tool-using inference in Astra's external deployment, at significant compute cost. Better model behaviour has arrived alongside more operational checking.

For a builder, that changes the definition of a completed integration. The workflow needs to handle a stopped run, preserve completed work, and report which action never happened. An answer that sounds finished is insufficient if the final tool call was blocked. Recovery behaviour belongs in the product specification.

Permissions are becoming part of agent distribution

Binance's 4 September Agent OS post describes a toolkit spanning trading, market data, wallets, and payments. The interface lets users configure and revoke permissions. Its MCP server currently covers trading and market data; other tools supply the wallet and payment functions. That distinction matters when describing what a single connection enables.

The post also describes a user connecting Codex to spot trading while each order still appeared for approval. It is a reported example, not proof that every Agent OS workflow applies an identical approval policy.

The useful signal is the product packaging. Access and its limits are being presented together. A user can authorise one kind of work without treating every capability of the connected account as part of the assignment.

That is a concrete requirement for any agent buying services. Permission to fetch a quote should not silently become permission to place an order. Permission to purchase one result should not expand because a retry loop keeps asking. The application must preserve the difference between the user's objective and the actions available through its credentials.

Enterprise buyers are purchasing controlled workflows

On 2 September, CrowdStrike announced that Falcon is coming to the Anthropic Claude Marketplace. Customers will be able to use part of their existing Anthropic commitments to procure the platform. The announcement describes Charlotte AI AgentWorks building agents grounded in Falcon telemetry and running security workflows directly from Claude.

The stated controls include scoped permissions, human-in-the-loop approvals, and auditability. This is an announcement of the offering, not a measurement of deployment volume or proof that every customer can already access it.

There is a commercial lesson here. The buying decision covers the workflow's data and controls as well as its model. Security teams need to know which systems an agent can touch and which actions require an operator. A natural-language interface makes the workflow easier to request; it does not remove that responsibility.

For agent developers, a clear account of permissions can therefore be part of the product's value. A buyer should be able to understand what granting access actually permits before the first task starts.

A paid Teneo command needs a clear boundary

Teneo gives builders several concrete places to make a task explicit. The Go Agent SDK defines task behaviour through `ProcessTask` and supports command pricing metadata. Users see pricing before execution, and the platform handles payment through x402. Agents begin private; changing commands or capabilities resets public status and requires another review submission.

Those mechanisms make the command a useful unit to reason about. They do not, by themselves, demonstrate that every client enforces a spending ceiling or asks for confirmation before every consequential action.

Consider a client that can make repeated paid calls. We would specify its permitted commands and total task budget before the first call, then decide how retries count against that budget. If the workflow can also change external state, we would give that action its own authorisation rule. These are implementation choices for the builder, not additional Teneo features being announced here.

Evidence also has to stay attached to the claim it supports. A payment record demonstrates payment. It does not establish that an answer is correct or that an input was current. Teneo Beacon's unused-bandwidth contribution concerns access to data; a client's checks on that data concern how it should be used. Neither replaces the other.

The next useful test

The practical test for this week's agent build is a stopped task. Set a limit, let the workflow reach it, and inspect what happens next. Does it stop before another paid call? Can the operator distinguish a completed query from an action awaiting permission? Is the remaining work recoverable?

Those questions turn the week's announcements into something a team can test. Start with one command in the Teneo SDK examples, define its permitted use, and verify the stopping behaviour before extending the workflow.