Cloud infrastructure. Secure automation. Systems that hold up.

Give agents useful access with explicit authority.

Problem

An authenticated browser session gives an agent access to far more than a single task requires. The engineering problem is to expose useful actions while keeping permissions inspectable.

Constraints

Work with existing sessions; bind actions to the intended origin; keep consequential actions subject to approval.

Decision

Separate the Rust bridge from the TypeScript browser runtime. Expose named, typed capabilities with schema validation, permission ceilings, single-use approvals, and lifecycle revocation.

Result & scope

An experimental capability broker with explicit permission boundaries and a documented threat model.

Tradeoff

Capability definitions and adapters require maintenance, but make authority narrower and easier to review than unrestricted browser control.

Keep data, decisions, and order authority separate.

Problem

A workflow joining market data, scheduled analysis, messaging, and order submission needs clear behavior when inputs are stale or services fail.

Constraints

Self-hosted operation, asynchronous updates, freshness requirements, and human approval for paper-order execution.

Decision

Use explicit service boundaries and immutable decision data. Validate freshness before acting, keep order authority with one writer, and separate analysis from human-approved paper orders.

Result & scope

A personal-use decision platform connecting data, validation, and approval workflows.

Tradeoff

More explicit state and service boundaries add coordination work, while making retries and authority easier to reason about.

Bound authority before adding tools.

An authenticated browser session carries more authority than most agent tasks need. In MCPatch, a useful tool starts with a named capability, a schema, and an allowed origin. The browser keeps its authentication material; the caller receives the capability result.

Approval is a separate boundary. Website content and model output are untrusted inputs, so neither can grant permission. Single-use approval and lifecycle revocation keep a previous decision from becoming indefinite authority. The tradeoff is more adapter and policy work for each capability.

One writer makes failure easier to reason about.

A trading workflow combines scheduled analysis, changing market data, and human decisions. I separate these responsibilities so a successful scan does not itself authorize an order. Immutable decision data and freshness checks preserve what was known at the decision point.

Order authority belongs to one writer, and paper orders require human approval. That creates extra coordination, but it gives retries and stale inputs a clear place to stop. The pattern applies beyond trading: separate recommendations from the component allowed to act.