When the agent can act

The risk in an agent integration is not determined by whether sign-in succeeded. It is determined by what the agent can do after sign-in, what the user can see before the effect, and which system can still stop or reverse the operation. This chapter applies the trust model from the previous chapter to the action spectrum represented in cursor/plugins, from read-only information to live orders and account-scoped changes.

The repository offers a useful vocabulary for that spectrum. Some connectors are read-only. Some produce drafts for a person to review. Some support previews before a live operation. Some add an explicit confirmation rule before writing. Others document actions that are charged, delivered, or placed in a real account. These are not interchangeable forms of “tool access.” They represent different effects and therefore need different controls.

Read-only is a real boundary

The Finance plugin describes a read-only connection to linked bank, card, and investment accounts. It can answer questions about balances, spending, subscriptions, and investments, but the README says the connection cannot move money into or out of bank accounts. That is a meaningful action boundary. It narrows the effect even though the data itself is sensitive.

Read-only does not mean consequence-free. The connector documents the categories of information shared and stored so it can work, including contact details, balances, transactions, credit and loan information, and investments. A responsible reader must therefore ask two separate questions. Can the agent change the account? What financial information crosses the connector and under whose privacy controls does it remain?

This is an important correction to a common shortcut. People often treat “no write” as equivalent to “no risk.” The repository’s own connector description suggests a more precise view. Read-only protects against one class of effect. It does not answer data minimization, retention, account linking, or host availability.

Drafts and previews create a reviewable middle state

Interactive Brokers documents a draft workflow. The agent can review positions, balances, activity, and market data, then draft trade instructions for review in the platform’s AI Instructions tab. The instructions do not become live orders automatically. The human retains a submission step inside the broker platform.

That draft state changes what verification means. The agent must produce an understandable instruction. The user must inspect the instrument, quantity, direction, and account context. The platform must make clear whether the instruction is still a draft. A successful tool call is not the same as a submitted trade. The boundary works because the system preserves an intermediate state that a person can evaluate.

Coinbase documents a different middle state. Its README says the server supports previewing and placing trades, warns that orders are live, and recommends previewing first and using an isolated portfolio. The preview is therefore not a cosmetic message. It is the point at which the agent and user can inspect the intended effect before it becomes an order.