Give Your Coding Agent Access to One Project

From the team behind aidrop.it — one workspace to build, host, and keep changing your code.

Give a coding agent a credential for the project it needs and the actions its task requires. Set an expiry and keep a way to revoke it. Before trusting that setup, check that the credential can read the intended project and cannot read a second test project you control.

A request to fix a checkout page does not require access to a separate client's repository. Writing that restriction in a prompt helps describe the assignment, but you also need the service receiving requests to enforce it. Choose the credential before handing the agent the task.

Separate reading from changing

Start an investigation with the permissions needed to inspect the repository and deployment state. Add write or deployment access when the work requires it. Record who approved that change and why. An agent diagnosing a failed release and an agent publishing its replacement have different jobs, even within the same conversation.

Read access still deserves care: code, logs and project notes can contain information you would not publish. Review which tools the connection exposes and which credentials the agent already has elsewhere. A narrow project token cannot constrain a separate shell session that holds an organisation-wide administrator key.

Check what the server refuses

Test the boundary with two disposable projects under your control. A credential for project A should succeed on an allowed read in A and fail on the same read in B. Test a forbidden action without changing live data. Then revoke the credential and confirm that a fresh request fails.

Use the actual API or tool connection that the agent will use. Hiding a project in a menu proves little about access to its records. Save the result and the credential's non-secret identifier. Do not put the token itself in a ticket, repository or screenshot of the test.

Review access when people and tasks change

Name a credential after its purpose and owner so someone can decide whether to keep it. Review it when a contractor finishes, a debugging session ends or responsibility for a project changes. Revocation prevents future authorised requests through that credential; it cannot recall files an agent already downloaded. The Git credential the agent pushes with deserves the same review, because a push is the only door code should enter a host through.

Treat this as part of taking over an existing codebase. The next maintainer needs to know which integrations remain connected and who can remove them. Keep that list beside the project's working rules so a new session can inspect the same boundaries before continuing.

Keep an access acceptance record

Use this checklist for a new agent connection or a review of an existing one. Fill in the allowed actions before testing, and use disposable resources for denied writes. Assign the revocation check to someone who can administer the connection; the person running the agent may not hold that permission.

AGENT ACCESS CHECK
Project / task / human owner:
Credential identifier (never the token):
Allowed read actions:
Allowed change actions:
Expiry / reason for duration:
Other credentials available in the agent's environment:

[ ] Allowed read in the intended project succeeds
[ ] Read in another controlled test project fails
[ ] Forbidden action against a disposable resource fails
[ ] Revocation prevents a fresh request
[ ] Replacement credential has the intended permissions
[ ] Owner knows where to revoke the replacement

Evidence location / review date:
Downloaded material to remove after the task:

FAQ

Is an instruction file an access control? It tells the agent how you expect it to work. The receiving service must check credentials and permissions before returning records or accepting changes. Use both, and review the proposed change before release.

How does aidrop.it scope a coding assistant? An aidrop.it Project grant identifies one Project and carries permissions and an expiry. A Project owner or admin can revoke it. That grant does not fall back to another Project or the Team's wider context. The access model describes the boundary.

Does revoking the project grant remove Git access too? Check each credential separately. An agent may also hold a Git credential or an API key issued by another service. Include those connections in the access review and revoke them at their issuer when the task ends.