Add code-agent capability policies for repo access and shell execution

[dgenio]

Context

Coding agents combine LLM reasoning with powerful tools: filesystem reads/writes, shell commands, GitHub actions, package managers, test runners, browsers, and APIs. The core safety question is not whether the LLM “understands” code perfectly; it is whether the surrounding system constrains what the agent is allowed to do.

agent-kernel is the right place to model this as capability-based authorization.

Proposal

Add a policy model tailored to coding agents and software-repo workflows.

Example capabilities:

• repo.read.files
• repo.write.files
• repo.write.paths:<glob>
• shell.run.tests
• shell.run.package_manager
• shell.run.networked_command
• github.read.issues
• github.write.issues
• github.create_pr
• github.merge_pr
• secrets.read / explicit deny by default

Policy ideas

• Least-privilege defaults for code agents.
• Step-scoped capabilities: inspect, plan, edit, test, publish.
• Escalation flow when an agent needs broader rights.
• Human approval for destructive, networked, or publication actions.
• Auditable records of capability grants and denials.

Acceptance criteria

• Define a minimal coding-agent capability vocabulary.
• Add example policies for read-only review, local edit/test, and PR-creation workflows.
• Support path-scoped write permissions.
• Support command-category permissions for shell execution.
• Add audit events for grants, denials, and approval requests.
• Document how this integrates with AgentFence and ChainWeaver.

Notes

This complements structure-aware context and validation: even good context should not imply unlimited tool power.

[ofekron]

I would model coding-agent capabilities as scoped action envelopes rather than broad labels.

For example, a grant should bind: actor/session id, repo root, path scope, command class, network/API class, secret boundary, side-effect class, expiry/turn scope, and whether the approval is one-shot or reusable. The audit event should record the requested envelope, resolved policy, human decision if any, and actual tool invocation. That prevents shell.run or repo.write from becoming ambient authority.

I maintain Better Agent (https://github.com/ofekron/better-agent), where local agents can mutate real repos and run shells, so this boundary is a core runtime concern. If useful, a star helps other coding-agent safety/runtime builders find it.

This comment was drafted with AI assistance and reviewed by me.