Agentic Coding Interview Permission Gates: What to...

The coding agent asks to run a command. The approval button is obvious; the effect is not. One click might read a local file, rewrite a directory, contact an external host, or execute with privileges that make recovery harder.

In an agentic coding interview, the permission gate is not dead time. It is a visible engineering decision. Major coding-agent products document sandboxes, approvals, and security boundaries in different ways. Their implementations are not interchangeable, but they support one durable rule: understand scope, reversibility, data exposure, and verification before authorizing an action.

Read the Permission Gate as a Change Contract

A useful approval starts with a concrete sentence: “I expect this action to do X to Y, and I will verify it with Z.” If you cannot complete that sentence, you do not yet understand the request.

The dialog itself may show only a command or capability. Your job is to reconnect it to the interview task. Why is this action necessary now? Which files, processes, credentials, or remote services could it reach? Can the same result be obtained with a narrower read-only inspection?

The broader AI interview tool rules guide covers whether a tool is permitted at all. This article assumes use is allowed and focuses on the moment-to-moment technical decision after a tool asks for more authority.

This guide focuses on approval judgment. Testing, rollback, and communication appear only as evidence for deciding whether an action should proceed.

Why Weak Approval Habits Fail

The first weak habit is automatic approval. The candidate assumes that a sandbox or permission dialog has already made the decision safe. Yet a sandbox can have configurable boundaries, a write can still damage the scoped repository, and network access can still disclose information the task never required.

The second weak habit is automatic refusal. It sounds cautious but ignores task value. Reading a test file, running a repository-provided check, or writing the exact scoped patch may be necessary and recoverable. Refusing everything prevents the candidate from demonstrating controlled execution.

The third weak habit is approving based on command familiarity. A familiar package command can execute project scripts. A familiar version-control action can discard work depending on flags and state. A familiar installer can contact a registry and change a lockfile. Names do not establish blast radius.

The fourth is narrating only after something goes wrong. Saying “I did not realize it would touch that” tells the interviewer that the approval was not tied to a prediction. A strong gate produces a prediction before execution.

Classify the Action Before You Click

Use four layers. They are not vendor-specific permission names; they are a reasoning model.

Layer one: observation

Read-only inspection includes listing files, reading source, checking status, and viewing an existing diff. Confirm that the command truly stays read-only and that it does not print secrets or huge unrelated data into logs.

Layer two: local mutation

File writes, formatters, generators, dependency updates, and test commands with fixtures can change the workspace. Name the expected files, check the working-tree baseline, and decide how you will isolate or reverse the change.

Layer three: external connection

Network access can download dependencies, query documentation, send telemetry, or transmit command context. Ask which host or artifact is required and whether repository content, tokens, personal data, or interview material could leave the environment.

Layer four: elevated or external side effect

Privileged commands, system configuration, deployments, database writes, messages, and remote mutations deserve the highest bar. A local rollback may not reverse them. If the interview task does not clearly require the side effect, pause and propose a safer substitute.

The harness engineering guardrails guide is a useful adjacent read because it treats permissions as one layer in a broader control system, not as a guarantee.

Use a Strong Approval Workflow with Checkpoints

Before approval, walk through four checkpoints.

Purpose: connect the command to one acceptance criterion. If it solves no stated need, remove it.

Boundary: name the allowed target. “Write the test file” is better than “edit as needed.” “Fetch this public package metadata” is better than unrestricted browsing.

Recovery: identify the known-good state and the action needed to return there. For a local edit, that may be a clean branch or an inspected patch. For an external mutation, recovery may require a compensating operation and therefore a separate approval.

Evidence: state what output will confirm the prediction. After execution, compare actual touched files, exit status, diff, and logs with that prediction.

If any checkpoint is unclear, narrow the action. Replace a recursive write with one explicit file, a broad network request with a named source, or a destructive operation with a preview. If narrowing removes the value, explain why you are pausing.

Interview AiBox can be used during preparation to rehearse these ten-second approval explanations and recap which risk category you missed. It should never be used to bypass employer policy or to normalize blind approval.

What the Interviewer Is Observing

The interviewer is not looking for theatrical caution. They are watching whether your control level matches the consequence.

For a read-only command, a short scope check may be enough. For a formatter that can touch the repository, they expect a working-tree baseline and a diff check. For network or privileged access, they expect a clear necessity argument, data boundary, and recovery plan.

They also watch whether you can challenge the agent constructively. “No” without an alternative can stall the task. “I will not approve a repository-wide write; I will approve a write limited to these two files after we inspect the current diff” preserves progress while reducing risk.

Finally, they watch whether you update your model after execution. If the command touched an unexpected file, stop. Do not approve the next action until you understand the deviation.

A Concise Spoken Approval Pattern

For a local write, say:

“This action is needed to update the handler and its focused test. I expect writes only in those two files, the working tree is otherwise understood, and I can inspect or discard the patch before any commit. I will approve the bounded write, then check status, diff, and the targeted test.”

For a risky request, say:

“The agent is asking for network access, but the current acceptance criterion can be verified from local code and existing dependencies. I am pausing this request and will use the repository-provided test first. If an external artifact becomes necessary, I will name the source and exclude repository secrets before asking again.”

The screen-share risk-control playbook offers related operational discipline, especially when command output itself may reveal information on a shared screen.

Failure Recovery and Residual Risk

Suppose you approved a formatter and it changed thirty files. Stop further actions, inspect exactly what changed, preserve any relevant output, and separate the intended edit from mechanical churn. Do not accept the large diff merely because it is syntactically valid.

Suppose a network command ran successfully. Success does not prove that no data was exposed. Review command arguments, environment use, logs, destination, and any created files. If a secret may have left the environment, local rollback is insufficient; the correct response may require credential rotation or incident reporting outside the interview scope.

Residual risk remains after every gate. A sandbox may have implementation limits. A read command may expose sensitive output. A reversible file edit may still waste time or hide a logic error. State the remaining risk instead of treating approval as a safety certificate.