An APX Approval Scope Is a Real Boundary, Not a Convenience Button

A permission prompt looks small: approve or deny. But the important question is not only whether an agent may run a tool. It is how far that approval reaches.

APX treats that reach as an explicit boundary. A one-time approval is one execution. A session approval belongs to one conversation. An always approval belongs to one agent, including later conversations and a restart. Those are different decisions, so they must not blur into one friendly-looking button.

The dangerous shortcut

Many agent products make approval feel like a binary switch. A person allows a harmless read, then later discovers that the agent stopped asking. The original decision silently became broader than the person intended.

That is especially risky when a tool can receive different arguments over time. Approving a request to read one note is not necessarily approval to read every note, call a different endpoint, or let a second agent act in another chat.

APX starts from the narrowest useful default: once. The approval runs the pending tool call, then disappears. The next request creates a new prompt. No permanent grant is created as a side effect.

Agent: use notes.search({ query: "release checklist" })
Human: approve once
APX: runs that call

Agent: use notes.search({ query: "customer contracts" })
APX: asks again

The second prompt is not friction by accident. It preserves a chance to notice that intent or data changed.

Choose scope deliberately

APX exposes three scopes for an eligible approval:

• once: only pending call; no saved grant.
• session: later turns in same chat can use tool, even when arguments change. Other chats still ask. Revocation can remove grant.
• always: same agent can use tool across its chats and after runtime restart. Other agents still ask.

This makes a practical review habit possible. Start with once while learning what an MCP tool does. Move to session when a single conversation needs repeated work. Choose always only when tool, agent, and long-term purpose are all known and acceptable.

The boundary is not merely user-interface language. APX tests that a session grant does not unlock another chat, that an always grant remains tied to its agent, and that revocation restores a prompt. It also rejects attempts to turn a denial into a wider grant; agents themselves cannot grant permissions.

Separate tool trust from project context

This is runtime policy, not portable project context. APC carries the repository-owned contract: AGENTS.md, .apc/, agent definitions, skills, and durable team guidance. It can say that a project uses a particular workflow or needs careful handling.

APX is the local runtime that executes a particular conversation. Approval records, pending prompts, and revocations describe a local operational decision. They should not become a hidden rule inside a portable repository. A fresh checkout should inherit documented project intent, not someone else's unreviewed tool grant.

That separation also keeps responsibility clear. APC can explain why a project needs a tool. APX asks a human whether this agent may use it now, and for how long.

A small rule that scales

Treat every broader scope as a new claim:

1. This call is safe now.
2. This conversation can repeat it.
3. This agent may keep doing it later.

Each step needs more evidence than the last. A scope selector that reflects that difference turns permission from a vague comfort signal into an auditable control boundary.

APC keeps project intent portable. APX keeps operational authority local, explicit, and revocable. That is slower than silently upgrading one approval into permanent trust—but much easier to trust in real work.