Scoped credentials and the kill switch
Limit what each agent can read and change, stop new and active work, and test that temporary permissions expire without relying on instructions alone.
Give each agent only the access its task needs, and enforce those limits in its tools and environment. A kill switch should prevent new work and stop further actions by active workers. Stopping a process does not undo requests it already sent.
A review agent needs to read a branch and report findings, not deploy it. If it starts posting unwanted comments, you need to stop that run's writes as well as prevent another run from starting. Pausing tomorrow's schedule does not stop today's worker.
“Do not deploy” is an instruction. A worker without deployment credentials or a permitted deployment tool is also restricted by the system. Design the second kind of protection for actions that must not depend on the model interpreting every message correctly.
Limit the operations each task can perform#
Start with the task, not a shared service account. A reviewer, builder and deployment verifier do not need the same operations. Write down what each may read, change and publish, including the target repository, environment and records.
Use short-lived credentials where supported and keep the permissions as narrow as the provider allows. A run may receive a token through a secret broker without the model seeing the secret itself. Never commit the credential or bake it into the worker image.
Check the actual permission model. A repository-scoped token may still permit writes to more branches than the task should touch. An issue tracker may not offer field-level restrictions. Add repository rules or a tool that validates the target before writing; do not describe a desired restriction as something the credential already enforces.
| Situation | Take | Because |
|---|---|---|
| A planning agent assessing a request | Read and add an assessment | Allow an assessment on the assigned task without overwriting the original request. Enforce that through supported permissions or a restricted tool. |
| A review agent examining an open change | No code writes | It reads the required code and reports findings on the permitted change. It cannot push a fix or merge the branch. |
| A builder implementing an accepted task | Restricted branch writes | The example policy permits its working branch and approved task updates, not merge or deployment. Enforce branch limits where the token alone cannot. |
| An incident analyser reading production logs | Only relevant diagnostic data | Limit logs and any necessary code to the investigation. Keep production writes unavailable and restrict what may be copied into a ticket. |
| A verifier testing a change before release | Test environment only | Its tools and credentials target the test environment. Production checks, where required, use a separate explicitly permitted workflow. |
- Situation
- A planning agent assessing a request
- Take
- Read and add an assessment
- Because
- Allow an assessment on the assigned task without overwriting the original request. Enforce that through supported permissions or a restricted tool.
- Situation
- A review agent examining an open change
- Take
- No code writes
- Because
- It reads the required code and reports findings on the permitted change. It cannot push a fix or merge the branch.
- Situation
- A builder implementing an accepted task
- Take
- Restricted branch writes
- Because
- The example policy permits its working branch and approved task updates, not merge or deployment. Enforce branch limits where the token alone cannot.
- Situation
- An incident analyser reading production logs
- Take
- Only relevant diagnostic data
- Because
- Limit logs and any necessary code to the investigation. Keep production writes unavailable and restrict what may be copied into a ticket.
- Situation
- A verifier testing a change before release
- Take
- Test environment only
- Because
- Its tools and credentials target the test environment. Production checks, where required, use a separate explicitly permitted workflow.
The table is an example policy, not a mandatory division of agent roles. Each denied action needs an enforcement point. For instance, a planning tool can allow adding an assessment while rejecting a request to replace the original description.
Inspect outbound routes as well as read access. A comment, uploaded artifact or model request can carry data outside the worker. Allowing only a tracker hostname does not prevent disclosure when the selected ticket is visible to someone who must not see the data.
Invariant Labs’ GitHub demonstration shows why permissions must be considered together. Its recommendation to restrict repository access helps with a cross-repository leak. It does not replace checking the output audience or other possible writes. The prompt-injection guide traces those combinations in more detail.
Stop the affected work, including active runs#
The example below offers four scopes: stop the whole factory, one workflow, work on one service or one individual run. These are useful when a problem affects only part of the system. They are not four services every team must build.
Define what each stop does. Preventing dispatch stops new workers. It does not stop a worker already editing files or holding a valid API token. Active workers need their own cancellation and denied-action path.
Record the stop where the dispatcher and write controls can enforce it. Check before dispatch and before consequential actions. A ticket label may communicate the state, but another automation must not be able to clear the effective stop by relabelling the task.
Cancellation can terminate the worker and revoke credentials when the provider supports immediate revocation. Otherwise, deny access through a gateway or other enforceable boundary and account for the credential’s remaining lifetime. A short expiry limits a window; it is not an instant stop.
A request already accepted by an external service may still complete. Save the attempted operation and check its result before resuming or retrying. Stopping the caller cannot unsend a message or automatically reverse a completed database write.
Give authorised responders a control that does not depend on the agent cooperating. Define a backup and a separate decision to resume. Before resumption, check outstanding external actions, ownership of the task and whether the saved code is still current.
Test with a harmless blocked operation in a non-production environment. Start a worker, trigger the stop and check that subsequent writes are denied. Try a delayed worker and a retry event too. A dashboard changing to “stopped” is not proof that the tools stopped accepting actions.
Check that access expires and stops still work#
Imagine a debugging session that needs extra read access for an afternoon. Record the reason, scope, approver and expiry with the grant. Make expiry remove the access where possible, then verify the effective result. A ticket reminding someone to remove it is weaker than an enforced expiry.
Review permission changes as configuration changes. Generate an access report from the configuration and compare it with effective provider permissions, rather than maintaining a reassuring table that no longer matches the system.
A failed task on a narrow token needs investigation. The task may legitimately need another operation, or the worker may be targeting the wrong repository. Broadening the token without resolving that distinction can hide the original defect.
Exercise stops after changes to the queue, worker runtime, credential provider or agent harness. Include old workers that wake after losing ownership. The OWASP guidance supports least privilege and layered checks; the particular stop scopes here are a proposed operating design.
A restricted worker still needs somewhere useful to run. Disposable environments and invented test data help separate testing from real users. To check whether the configured agent works inside those limits, continue with a reusable set of evaluation tasks.
IF YOU REMEMBER ONE THING
Check actual permissions and actual denied actions. A short-lived token is not instant revocation, a paused schedule does not stop active workers, and cancellation does not undo an external action.
Questions people also ask
4 QUESTIONSHow should a coding agent's credentials be limited?
Grant only the repositories, environments and operations needed for the task. Prefer short-lived credentials and keep secrets out of prompts, images and source control. Where the provider cannot restrict a token to one branch or record, add an enforcing gateway or repository rule; do not claim a restriction the token does not support.
Does every factory need four separate kill switches?
No. Global, workflow, service and individual-run stops are useful scopes in the example here. A small system may combine some of them. What matters is knowing which work stops, how quickly active actions are denied and how an authorised person safely resumes it.
Who should be allowed to stop the agents?
Name the people responsible for the affected service and the factory, with an appropriate backup. Give them a tested way to stop work without requiring the failing agent's cooperation. Define who may resume it too. The exact response arrangements depend on when the factory operates.
How do temporary permissions avoid becoming permanent?
Record their reason, scope, expiry and approver when granting them. Remove or expire the grant automatically where possible and check the effective permissions afterwards. A note saying temporary is not an access restriction.