Proposal: Make permission checks required for file writes and terminal execution

[ZhengShenghan]

Problem

The ACP specification defines session/request_permission as a MAY-level mechanism; agents can request permission before sensitive operations, but are not required to. For fs/write_text_file and terminal/create, this means:

• An agent can write to any absolute path without permission
• An agent can create and execute terminal commands without permission
• The only constraint is that paths must be absolute (no path sandboxing, no allowed-directory restriction)

Given that ACP agents (coding agents like Claude Code, Codex CLI, Augment Code) have direct filesystem and terminal access, the security impact of skipping the permission check is high: an agent acting on untrusted input could write to security-sensitive locations or execute arbitrary commands.

Evidence

We analyzed the Python SDK (agent-client-protocol v0.9.0):

1. write_text_file does not check permission:

# In AgentSideConnection, the write_text_file method:
async def write_text_file(self, content, path, session_id, **kwargs):
    # Calls the client directly — no permission check
    return await self._conn.send_request(...)

There is no call to request_permission before write_text_file. An agent can write to any path without asking.

2. create_terminal does not check permission:

Same pattern — terminal creation proceeds without any permission gate.

3. No path restriction exists:

# The spec requires absolute paths but nothing else:
# - No allowed-directory list
# - No workspace boundary check  
# - No file type filtering
# - No content size limit

4. The permission mechanism exists but is optional:

# ACP has request_permission — this is actually unique and good!
# But it's MAY-level, so agents can skip it entirely.
async def request_permission(self, options, session_id, tool_call, **kwargs):
    # options include: allow_once, allow_always, reject_once, reject_always
    ...

Proposed Change

Make request_permission mandatory (MUST) for operations that modify the filesystem or execute commands(at least for the credential files or system files like .ssh/authorized_keys):

• fs/write_text_file — MUST request permission before writing
• terminal/create — MUST request permission before creating a terminal
• terminal/kill — SHOULD request permission

The existing request_permission mechanism with allow_once/allow_always/reject_once/reject_always options is well-designed for this — it just needs to be required rather than optional for these high-impact operations.

Additionally, consider adding workspace-scoped path restrictions:

# During session/new, the cwd establishes a workspace boundary.
# write_text_file should reject paths outside cwd unless the
# client explicitly grants broader access.

Why This Matters

ACP-Client is used by coding agents that operate on users' source code. When these agents are connected to external tools (e.g., via MCP), content from untrusted sources can influence agent behavior. If the agent writes untrusted content to the filesystem without permission, the result is effectively arbitrary code execution in the user's development environment.

The permission mechanism already exists and is well-designed. This proposal just makes it mandatory where the security impact is highest.

[ZhengShenghan]

Additional context — cross-protocol composition risk:

When ACP-Client agents also use MCP tools (as Claude Code, Codex CLI, and JetBrains agents do), the lack of mandatory permission becomes a cross-protocol injection risk. MCP tool responses contain attacker-controlled content (web pages, database rows, git commits) with no sanitization or source marking. This content flows through the agent's context into write_text_file and create_terminal without any permission check.

Making permission mandatory for these operations would provide a defense-in-depth layer against cross-protocol injection, even when the upstream protocol (MCP) fails to sanitize its output.

We have reported the MCP-side issue separately to the MCP maintainers.

[ZhengShenghan]

Additional findings from formal security analysis

Beyond the filesystem/terminal permission issue above, our analysis of the ACP-Client specification and Python SDK (v0.9.0) identified several additional areas where security infrastructure could be strengthened. These are design recommendations for future protocol development.

1. Capability attestation: Annotations has audience, priority, and last_modified but no signing or verification fields. Agent capabilities are self-declared with no independent verification.

2. Audit: No audit infrastructure in the SDK — no event logging, no operation history, no hooks for recording security-relevant events. For coding agents that modify source code and execute commands, audit trails are important for accountability.

3. Credential lifecycle: No credential management — no session timeout, no refresh mechanism. close() performs no credential cleanup.

The existing request_permission mechanism is architecturally sound and unique among agent protocols — extending it as proposed above would address the most critical gap. These additional items are lower priority but worth considering as the protocol matures.

[benbrandt]

Hi, this is the responsibility of each agent, as they often have their own permission setups with different settings and mechanisms for users who want to allow many actions to occur without a need for them to explicitly allow it.

If we enforced this at the SDK level, people who use more automated flows would be frustrated that it was asking them for permission every time.