What permissions should AI engineering agents have?

An agent becomes operationally significant when it can act. Reading a repository, modifying files, running commands, opening a pull request and deploying software are different capabilities with different consequences. A single “AI access” switch hides those distinctions.

Permission design should make the intended path possible while limiting what a mistake, compromised dependency or malicious instruction can affect. This is standard least-privilege engineering applied to a system that may choose and sequence actions.

Map the task before granting access

Define the goal, expected artefacts and acceptance criteria first. Then identify the smallest set of repositories, directories, tools, services and data needed to complete it. Specify prohibited actions and a time or cost boundary. If the task cannot be bounded clearly, it may not be ready for agent execution.

Consider permissions in layers. Read access can expose confidential code or data. Write access can corrupt or obscure work. Command execution can affect the environment. Network access can disclose information or introduce untrusted content. Merge and deployment rights can turn an unreviewed change into a customer or operational effect.

Do not infer safety from an agent's job title or prompt. Enforcement should come from the surrounding identity, repository, environment and platform controls.

Apply least privilege and separation of duties

Use a dedicated identity so agent actions can be distinguished from human activity. Scope it to the task and expire access when the session or job ends. Prefer a new branch, temporary workspace or sandbox over direct changes to a protected branch. Restrict external connections to approved destinations and expose only trusted tools.

Separate creation from acceptance. An agent that generates a change should not normally approve and merge that same change. Production deployment, destructive data operations, credential changes and broad infrastructure actions deserve independent approval and stronger technical controls. For a low-risk workflow, pre-approved automated steps may still be appropriate within tested boundaries.

GitHub's current responsible-use guidance illustrates this pattern: agent access is repository-scoped, default-branch pushes are constrained, secrets must be deliberately provided, and some workflow activity requires human approval. Product details vary, but the underlying design principles are transferable.

Protect data, credentials and tool connections

Give the agent task-specific credentials rather than a person's long-lived identity. Use short-lived tokens where the platform supports them, restrict each secret to the required action and prevent credentials from appearing in prompts, logs or generated files. Test what happens when access expires or a service is unavailable.

Treat connected tools and external context as part of the trust boundary. A tool can expose additional data or execute actions beyond the repository. Untrusted issue text, documentation or tool output may contain instructions that conflict with the task. The agent should not gain authority merely because content asks it to do something.

Maintain an inventory of approved tools, their owners, the data they can reach and the actions they permit. Review connections and credentials when vendors, models or workflows change.

Verify containment and recovery

Before broadening permissions, test failure deliberately. Can the agent write outside the intended directory, contact an unapproved service, reveal a secret, alter its own controls or continue after revocation? Can the team stop the session, identify every action and restore the affected state?

Monitor denied actions and repeated requests for broader access. They may reveal poor task design, missing capability or attempted boundary crossing. Do not automatically convert frequent prompts into permanent permission; understand why the access is needed.

Increase permissions in small steps after representative trials show acceptable quality, review effort and recovery. Reassess when the work, environment or potential blast radius changes. The safest useful permission set is not static: it is the narrowest set that continues to support an evidenced delivery need.

Example

An agent handles routine dependency updates in one service. It can read and write that repository, use an approved package registry and run tests in an isolated environment. Its token expires after the task. It cannot read other repositories, access production secrets, modify workflow protections, merge its branch or deploy.

If a test needs a temporary service, the agent can request a pre-approved sandbox resource. A maintainer reviews dependency provenance, the change and test evidence before merging. An attempted connection to an unapproved registry is denied and logged for investigation.

FAQs

• Should an AI engineering agent have production access?

  Usually not by default. Where an evidenced use case genuinely requires it, scope access to specific actions and resources, use strong approval and monitoring, and test revocation and recovery.

• Can an agent use a developer's credentials?

  A dedicated, task-scoped identity is safer and more auditable than sharing a person's long-lived credentials. It also makes revocation and separation of activity clearer.

• Is read-only access low risk?

  It reduces the chance of direct modification but may still expose source code, personal data, secrets or commercially sensitive information. Grant read access according to the sensitivity and necessity of the data.