Policy template
Agent permissions in one page
What an AI coding agent may and may not do in your repository, cloud, and data, with how to enforce each line. Ready to copy into a policy.
I'm starting to see coding agents run with a personal access token. That token can push to main, read every secret, and call production APIs. The agent is fast and mostly right. That's exactly why the one wrong change slips through.
I treat agents as untrusted contributors. They get scoped permissions, the same checks as humans, and a human on every merge that matters. The table below is that rule, line by line.
From the talk: Ship fast, break nothing: CI/CD for vibe-coded startups
The policy
| Area | The agent may | The agent may not | How we enforce it |
|---|---|---|---|
| Repository | Open branches and pull requests, and comment. | Push to main, merge, approve its own work, or edit workflow files. | A branch ruleset with no bypass for the bot, and CODEOWNERS on .github/. |
| Identity | Act as its own bot account or GitHub App. | Use a person's account or personal access token. | A GitHub App with the fewest permissions. Its installation tokens expire after an hour. |
| Secrets | Use the secrets of its sandbox. | Read production secrets or long-lived cloud keys. | Production secrets only in an environment with required reviewers. |
| Cloud | Read and write in a sandbox account. | Reach production accounts. | A separate account, with OIDC roles scoped to it. |
| Data | Work with synthetic or anonymised fixtures. | Read production customer data. | No production credentials in the sandbox, and no copies of production data there. |
| Runners | Run in fresh, isolated runners. | Run on a laptop or a runner with a network path to production. | GitHub-hosted or ephemeral runners only. |
| Outside input | Read issues, web pages, and READMEs as data. | Follow instructions found in them. | No secrets for workflows that outside contributors trigger. |
| Review | Review code as an extra reviewer that comments. | Give the approving review. | A required approval from a human code owner. |
| Record | Act under its own identity, with every action in the log. | Act anonymously or under a shared login. | An audit log we keep, so last week's agent changes are one query away. |
When to give an agent more
I raise autonomy one area at a time. The trigger is the agent's change failure rate matching the human engineers' rate. Products with LLM features need one more check. Their evaluation set runs in CI on every prompt or model change, as a check that can block a merge.
What I leave out on purpose
I leave out fully autonomous merge and deploy by agents, self-hosted model infrastructure, and multi-agent orchestration. Each one removes a human check before the metrics justify it. They can wait until the change failure rate says otherwise.
Next step
I highly recommend picking one repetitive task for an agent, such as dependency upgrades or test backfill. In thirty minutes we'll check whether it pays back and sketch the permissions it needs. Which task would your team hand over first?
Book a callThese takeaways are an engineer's reading of the rules and the tools. I wrote them to help teams decide what to build. They aren't legal advice. I recommend checking the current text with your own counsel before planning around a date or a threshold.
How I help
Cloud security hardening
I find the gaps in your cloud accounts, identity, network, and data, rank them by what an attacker reaches first, and close them with your team.
AI integration
I put language models to work on the problems that matter in your product and back office, and I ship them to production.
Other takeaways from this talk
Checklist
The 10-check vibe-coding safety net
Ten yes/no checks that turn a CI pipeline into the reviewer a solo founder or small team doesn't have. About a day of setup.
Template
Starter GitHub Actions workflow
A copy-ready CI workflow: lint, types, tests, build, dependency review, CodeQL, and an OIDC deploy from main with no stored keys.
Worksheet
DORA metrics in 15 minutes
A one-page sheet to measure deployment frequency, lead time, change failure rate, and time to restore from your Git and deploy history.
Let's talk.
A 30-minute call, no pitch. We look at your current setup, your stage, and the thing that's bothering you about it. I give a straight opinion on what to change, what to leave alone, and whether the problem is the one it looks like. What's the one thing in your stack you'd fix tomorrow?
Prefer email or phone? hello@netninjas.eu or +31 6 45984313