An agent autonomy setting looks like small metadata. It is not. It can decide whether a tool runs now or s for a human. That makes guessing the wrong response to invalid input.
APC provides portable project context: agent files, roles, skills, and project metadata travel with the repository. APX is the local runtime that reads that context, runs agents, and enforces tool permissions on the machine. The boundary matters here: a portable agent declaration may request an autonomy mode, but APX must turn that declaration into a real, local permission decision.
APX has three permission modes:
total: tools run without confirmation. automatico: safe work can proceed; destructive, outbound, runtime, MCP, and filesystem-mutating work can require confirmation.permiso: only allowed_tools run directly; every other tool asks.
A project has a baseline mode in its runtime configuration. An individual agent can declare Autonomy: to override that baseline for its own turn. An agent with no declaration inherits the project setting.
Imagine a project whose normal setting is automatico, and a review agent should be more constrained:
---
name: reviewer
role: Review pull requests
Autonomy: permiso
---
Now imagine someone edits the card and writes Autonomy: permissive. A permissive parser might map that to total, choose the nearest known word, or silently save a value that later means something else. Each path turns a typo into an authorization decision.
APX does not invent a mode. When it reads a stored autonomy field, an unrecognized value is dropped and the agent inherits the project baseline. That protects the runtime from treating garbage as a new, wider permission setting. It also keeps the effective policy explainable: either a recognized agent override applies, or the project policy applies.
There is an important nuance. Inheritance is not a substitute for validation. If the project baseline is broader than the author intended for that agent, a malformed stored value will not magically preserve the intended restriction. That is why APX handles direct CLI input differently: apx agent ... --autonomy rejects an invalid value and tells the user the accepted modes, including inherit. A person at a terminal gets a visible error instead of a plausible-looking success message.
Use these meanings consistently:
no --autonomy flag keep current agent setting
--autonomy inherit clear agent override; follow project mode
--autonomy automatico set explicit agent override
--autonomy permiso set explicit agent override
--autonomy total set explicit agent override
Then verify the result in the agent file and test an action that should . Configuration text alone is not evidence that the tool loop uses it. APX applies a valid agent override to the active turn configuration before its permission guard and risk handling run.
The portable side should say who the agent is and, when useful, its intended operating boundary. The runtime side must decide what the current machine can actually execute, prompt on, or deny. APC does not become a hidden authorization database; APX does not treat a typo as authority.
That division makes agent behavior safer to review. A teammate can inspect the declared agent contract in the repository. The local runtime can enforce it without copying private runtime state back into APC. And when an autonomy value is wrong, the system has one honest answer: stop guessing and fix the value.