AI Agent Access Control in AuricIDE

What goes wrong when a review agent can act?

A review becomes unsafe when its launch settings let the agent move from inspection into action without a deliberate boundary.

The repository is open, and the task says "review." The agent reads the diff, then edits a test, calls another tool, and stops at an approval prompt. Nothing in the word "review" prevented that.

The first explanation is easy: the agent had too much access. That's partly true. It misses the mechanism, though. The launch settings did not match the job. A read-only assignment became an interrupted work session, because the chosen CLI mode allowed a wider path than the task needed.

Access control for a coding agent isn't a role you assign once. It's a decision attached to each run.

A repository permission only answers part of it. The agent may need files, project records, and tools, yet still need to stop before changing anything. An implementation task has another shape: it must edit, run checks, and perhaps update a ticket. Both tasks can use the same CLI, and giving that CLI one permanent identity hides the decision that matters. What this run may do.

A chain makes the problem sharper: a safe review step can hand context to an implementation step whose mode permits changes. The harmless first step does not make the second safe. Each step needs its own decision before execution. That decision rests on its prompt, tools, and how much human attention it expects.

The distinction matters for anyone coming from agentic coding fundamentals. Stable roles describe people well, because their duties persist across sessions. An agent can move from reviewer to implementer with one new prompt, so access belongs to the work unit, not the agent's name.

How does AuricIDE set that boundary?

AuricIDE sets the boundary in each skill. There you pick a provider, model, prompt, and a permission mode the provider defines, before launch. Open a skill, and its settings show those four choices together. Pick the provider first. The permission menu then reflects the modes exposed by that provider's CLI, including its default. A skill stores one permissionMode value, and AuricIDE does not translate it into a product-wide role such as "reviewer" or "developer." This order matters. A similarly named mode can carry different behavior in another CLI. The provider decides what happens. AuricIDE just surfaces the choice.

Providers can also be added at runtime through JSON configuration. AuricIDE validates the config against the provider schema. It rejects malformed JSON outright. It never registers a partial provider. Once registered, that provider supplies its own models, permission modes, and defaults to skill settings.

Now launch the skill. AuricIDE starts the selected provider with the saved prompt, model, and mode. The running agent shows its terminal activity. If that CLI's mode requires approval, the run waits for it. If the mode allows non-interactive work, the CLI can continue. The mode name alone proves nothing. So the provider's own documentation stays part of setup.

Chains repeat the choice at every step: a review skill can ask before acting, while a later implementation skill can use a mode suited to bounded execution. The next step receives its own prompt plus a cleaned terminal tail from the prior step: AuricIDE strips ANSI, filters terminal chrome, removes duplicates, and caps the result at 2000 characters. Context crosses the handoff. Permission does not.

That separation is visible and useful, but it also demands care. An unattended step can stall behind an interactive mode, while a broad mode can proceed without a checkpoint. Either mismatch defeats the task boundary.

What does this design cost?

The design costs central policy. AuricIDE has no product-wide role system. There is no log of which human approved an agent's access, either.

There is also no per-tool ACL. That's beyond what MCP exposes. If a provider exposes a tool, AuricIDE does not add another allow-or-deny rule above it for a particular skill. The skill's permission mode controls one thing only: how the selected CLI handles actions under that provider's own semantics.

This makes provider setup part of access control. The MCP server design guide is useful background for thinking about that boundary. A provider meant for review should expose only the project information and tools review needs, while an implementation provider may expose write-capable tools. AuricIDE will not fold those arrangements into one shared ACL for you.

That gap matters. No log says which human gave the final approval. A team that needs named approvers, roles set from one place, or per-skill tool grants has to get those controls outside AuricIDE. That limit is real. It should factor into whether the product fits a repo's rules.

There is more maintenance too. Every skill needs a deliberate mode. Every provider needs its behavior written down. Every chain needs a step-by-step check. A provider change can invalidate assumptions attached to a familiar mode name, and adding an MCP tool widens what's available through that provider.

AuricIDE keeps the provider's own permission model visible. It does not hide that model behind a universal vocabulary, which would promise an equivalence between CLIs that don't actually behave the same way. The price is local knowledge: whoever configures the skill has to understand the chosen CLI and the MCP tools exposed to it.

What should survive in any agent setup?

The durable rule: validate access per task, and test the exact launch path, rather than trusting a label.

Start from the job. List what the step must read, name what it may change, and decide whether a human has to confirm an action. Then pick a provider and mode that enforce that decision as closely as the CLI allows.

Test the skill alone first, and watch the terminal. Does a review attempt stop before a file change? Does unattended work pause on a prompt nobody can answer? Can the agent call an MCP tool the task doesn't need? These are behavior checks, not label checks.

Then test the handoff: inspect the cleaned terminal tail as input to the next step, not as proof of authority. Its 2000-character cap can omit earlier context, and what survives can still steer the next prompt. The receiving step keeps its own provider, mode, and tool boundary. That holds no matter what came before it.

The MCP server setup reference helps separate provider registration from skill behavior, and those are different checks. Valid JSON only proves AuricIDE can register a provider. It proves nothing about whether a permission mode fits a review, whether an MCP tool belongs in the boundary, or whether a chain can run unattended.

Run one failure on purpose. Ask a review skill to propose a small edit, against a repo you can throw away, and see whether the selected CLI asks, refuses, or just goes ahead. Then run the same skill inside its intended chain. Check whether the handoff changes the result. That short exercise reveals more than a role name, because it tests the provider, prompt, mode, tools, and context path together.

A task boundary has to be visible before launch, and observable while it runs. It also has to limit how much room a wrong prompt gets to act on.

AuricIDE is a local desktop workspace for running CLI coding agents as a coordinated fleet, with reusable skills, provider-based harness registration, chains, and MCP-backed project state. Visit AuricIDE to see how per-skill permission choices fit into a multi-agent repository workflow.