Security Risk Grades Are Not Permission Modes in APX

A permission toggle answers one question: may this tool run? It does not answer a second one that matters just as much: how dangerous is this exact action right now?

That is why APX keeps permission mode and security-risk grading as two separate runtime controls.

APC is the portable context layer. It gives the project one neutral contract in the repo: AGENTS.md, .apc/, agent files, MCP hints, skills, and other durable context. APX is the daily-use runtime and tooling layer. It reads that contract, runs the agent loop, and keeps runtime decisions like approvals, sessions, and message logs outside the repository.

This topic belongs on the APX side.

Two gates, two different jobs

APX supports three permission modes for the super-agent:

• total: run tools without confirmation
• automatico: APX decides automatically
• permiso: only allow-listed tools run directly

That gate is about tool identity. A shell tool, file editor, Telegram sender, or MCP call can have a default trust policy before the model even decides what to do.

APX also has an optional security_risk layer. When enabled, APX injects a required security_risk field into each eligible tool schema, and the model must grade the action as LOW, MEDIUM, or HIGH as part of the tool call itself. No second model pass. No separate risk service.

That gate is about action severity.

Those are not the same thing.

A tool like run_shell might be harmless for ls src and dangerous for rm -rf build. A send tool might be fine for an internal note and risky for an outward message to a real user. Static permission mode cannot see that difference by itself. The risk grade can.

Why this split matters

If you collapse both ideas into one setting, you get a bad tradeoff.

If the system is too strict, the agent asks for approval on every non-trivial step and stops being useful. If the system is too loose, one trusted tool can do a much riskier action than the user expected.

APX avoids that by keeping both layers:

• permission mode decides the baseline policy for a tool
• security-risk grading decides whether this call should stop

The most interesting case is total mode. In APX, the risk gate still acts as a safety floor. Low-friction work runs freely, but a HIGH-graded action can still require confirmation. That is a better model than all-or-nothing trust, because "I trust this agent" should not mean "I want zero brakes on catastrophic actions."

Small example

Imagine the same project agent, the same runtime, and the same shell tool:

apx permission set total

Now compare two actions the model could take:

1. grep -R TODO src/
2. rm -rf ./tmp/generated-cache

Permission mode alone sees one tool: shell.
Risk grading sees two different severities.

That distinction lets APX stay fast on ordinary work without pretending every shell call carries the same blast radius.

Why APC should not own this

This is exactly the kind of state APC should not carry.

APC should travel cleanly between repos, machines, and runtimes. A committed project contract should not silently force the same approval behavior everywhere. Approval thresholds, confirmation surfaces, and action gating are runtime policy. They depend on who is running the work, where, and under what level of trust.

So the repo keeps the durable project context. APX keeps the live control plane.

That split is the real point: APC tells the runtime what the project is. APX decides how safely that runtime can act today.

Comments

[Luis Cruz]

I appreciate how APX differentiates between permission modes and security-risk grading, acknowledging that tool identity and action severity are distinct concerns. The example with apx permission set total and the two shell actions - grep -R TODO src/ and rm -rf ./tmp/generated-cache - effectively illustrates the importance of this separation. By maintaining this distinction, APX can provide a more nuanced approach to security, allowing for low-friction work while still applying a safety floor for potentially catastrophic actions. How do you envision this security-risk grading evolving in APX, particularly in terms of integrating more sophisticated risk assessment models or machine learning algorithms to further refine the LOW, MEDIUM, and HIGH risk categorizations?