Who Gives the Agent Production Access? My Talk at Alan's Second Opinion in Paris

Key Points:

• The event was full. Alan, AWS and Qovery held Agents in production, part of Second Opinion by Alan, at Alan's office in Paris. Three talks on running AI agents in production.
• A human on every change is not a safety net. Anthropic says 97% of Claude Code permission prompts get approved. After a few hundred prompts, people stop reading.
• The real problem is permissions. Roles were made for humans. A role that can change something can usually delete it too.
• Check every operation at the API. A Qovery API Policy Token carries a policy written in Rego. Qovery checks it on every request, from every interface.
• Start with safe jobs. Cleanup and resizing first. Then tests on a copy of production. Then security patches.

On Thursday, November 12, I spoke at Agents in production: beyond the demo in Paris. It was the second edition of Second Opinion, Alan's tech event series. Alan, AWS and Qovery organized it together, at Alan's office on the Quai de Valmy.

The event was full. The room had engineers, CTOs and platform teams, many of them from healthtech.

Alan is a Qovery customer and a partner, and they know how to run a great in-person event. Thank you to Louis and his team for all the preparation.

This post is the written version of my talk, with the slides and photos from the evening.

The talks

There were three talks. Each one looked at the same question from a different side: what does it take to put an agent in front of real users?

Medical safety with stochastic parrots. Thomas Humeau, Full Stack Data Scientist at Alan, showed how Alan uses LLMs to help members with health questions. LLMs know a lot about complex topics, but they can fail on simple ones, and you can't predict when. So Alan built a system around the model. A flagging system sends conversations to a doctor for review, and 35 doctors are available 24/7. Doctors became a new type of user in the product.

Who gives the agent access to production? My talk, below.

Every token has a price and an address. Charline Boulie, Senior Solutions Architect for startups at AWS, talked about context engineering. Every token in the context window costs money. It is also data that you send, that gets cached, and that may be kept. She showed how to treat the context as a budget, to balance cost, answer quality and privacy.

My talk: who gives the agent production access?

I started with a definition. Production infrastructure is everything your customers use, right now: apps and services, data and backups, the network, secrets and access, pipelines and infrastructure as code, and observability. If it breaks, your customers see it. If it is deleted, you may not get it back.

Then I asked the room a question: who gives an AI agent full access to production? Raise your hand.

Almost no hands went up.

Full autonomy can destroy production

The room had good reasons.

In April 2026, a coding agent at PocketOS found an API token with more permissions than planned. It used the token to delete the production database and its backups, in one API call. It took 9 seconds.

In July 2025, an agent on Replit deleted a live production database during a code freeze, when changes were forbidden. Then it created fake data.

In both cases, the agent had more access than the task needed. Both incidents are in the OECD AI incident database.

What most teams do today

So teams keep a human in the loop. The agent reads logs, metrics and config. It finds what is wrong. It suggests a fix as a pull request, a ticket or a message. A human approves it. Then CI applies it. For infrastructure, that is usually Terraform: the agent opens a pull request, a human merges it, and the pipeline runs terraform apply.

This has real benefits. The human keeps full control. Every change is in Git. It works with the infrastructure as code and GitOps tools teams already use.

It also has costs. The agent can only go as fast as the reviewer. Every suggestion needs a human, small or big. Tired reviewers approve without reading. And during an incident, everything waits for a person to wake up.

Human in the loop, or just clicking yes?

The review also does not protect much.

In August 2026, Anthropic published that 97% of Claude Code permission prompts get approved. After a few hundred prompts, people stop reading and click yes. Anthropic then made automated review (auto mode) the default in Claude Code. You pay for the review with speed, and you don't get the safety.

Why agents still wait for a human

I see three reasons.

1. We don't trust their judgment yet. One wrong decision can delete a database in 9 seconds.
2. They can reach too much. One token often opens the whole account, production included.
3. Their permissions are not precise enough. Roles were made for humans. A role that can change something can usually delete it too.

Solve the third one, and the first two are solved too. An agent with bad judgment but a narrow permission can only do narrow damage.

Today, few companies take that step. The Grant Thornton 2026 AI Impact Survey says only 5% of organizations let agents make high-risk changes without a human review.

How we solved it at Qovery: API Policy Tokens

On August 26, we shipped API Policy Tokens, in preview. A regular API token carries a role. A Policy Token carries no role. It carries a policy, written in Rego, the language of Open Policy Agent. Qovery checks that policy on every API request. The policy is the token's entire authorization.

The policy lists exactly what the agent can do, and where. Every call goes to the audit log under the token's own name, policy:<token-id>:<token-name>. So you can always tell an agent's actions from a human's.

This works because every operation goes through the Qovery API. The console, the CLI, the Terraform provider and the MCP server all use it. The policy is checked in one place, for every agent. An allowed operation runs through the same tested pipeline as when a human clicks the button, and it is logged. Anything else is rejected.

A policy is a few rules anyone can read

Four things to know:

1. Deny by default. Anything the rules don't allow is rejected.
2. One allow rule per need. The token is allowed if one of the rules is true.
3. A rule is a list of checks. Inside a rule, every line must be true.
4. input is the API request. For every call, Qovery sends the method, the path, the environment and the service.

In this example, the agent can read everything. In production, it can only deploy.

You don't have to write this by hand. The qovery-policy-token skill takes what you want in plain English and writes the policy. Then it tests it for real: allowed calls must pass, and forbidden calls must be rejected.

Agents keep working on infrastructure as code

The agent still edits Terraform. CI runs terraform apply, with no human approval. The Qovery Terraform provider calls the Qovery API. The policy allows or rejects each operation.

Nothing changes in the repo or the pipeline. The check moves from the pull request to the API. Qovery's orchestration is deterministic: the agent chooses what to do, and the engine runs the same tested steps every time. You can keep pull request reviews for big, rare changes. The policy covers the rest.

Human approval vs API policy

Both give you full control. The API policy is instant, it does not get tired, and it covers every interface. A pull request review only covers the Git repo.

The API policy has limits too. Someone has to write the policies. And an action that is allowed but wrong still goes through. Deploying a bad version is allowed, so you still need tests and rollbacks.

The demo

The demo was a video: Claude Code, connected to the Qovery MCP server with a Policy Token.

• The agent read the logs, deployed a preview environment and deleted an old preview. All allowed.
• It tried to delete the production database. Blocked with a 401.
• It tried the same thing through terraform apply. Blocked with a 401 too, because the Terraform provider goes through the same API.

Every call then showed up in the Qovery audit logs, as an executed event or as "Access Denied".

To give an agent the same kind of access, start with the policies to investigate a production incident and to verify a fix in a preview environment.

The jobs agents can do on their own

With permissions this precise, a lot of real DevOps work can run without a human. I went from the simplest jobs to the hardest.

• Hygiene: stop idle dev environments at night and on weekends. Delete previews once the pull request is merged.
• Cost: set CPU and memory from real usage. Move non-production workloads to cheaper machines.

• Reliability: roll back a bad release. Add capacity before a known traffic peak.
• Change: patch a security issue. Test it on a copy, release it to a small part of production, then everywhere. Test an upgrade on a copy of production first.

Each job gets a policy that allows that job and nothing else. We published one page per job in the agent policy examples, with the use case, the full policy to copy, the prompt for the agent, and what the agent can and cannot do.

During the talk, I showed short videos of some of these agents:

• Cost agent. It read 30 days of usage, stopped idle dev environments and resized staging. It was blocked when it tried to resize a production service.
• Security patch agent. It fixed a CVE in the Dockerfile, cloned production, ran end-to-end tests, then deployed to production. It was blocked when it tried to change a production environment variable.
• Test agent. It cloned production without data, ran tests and deleted the clone. It was blocked when it first asked to copy the data.
• Right-size agent. It could change only the CPU and memory of 3 production apps. It was blocked on a replica change, and on an app outside those 3.
• The skill itself. From the request "allow my agent to optimize the performance of my production apps (CPU, memory, instances) and nothing else", the qovery-policy-token skill found the apps and wrote the policy. It passed 8 out of 8 local tests, then a live test on a copy of production without data. Then it cleaned up and created the real token.

What to remember

In one line: check operations at the API, not with a human on every change.

The rest of the evening

After the talks and the Q&A, the evening went on over drinks and networking.

Five days earlier at SREday NYC, I shared what about 280 teams told us over three years. One lesson was to gate every write to production. This talk showed how to keep that gate without a tired human behind it, by checking every write at the API.

If you run a meetup or a conference and want this talk, or want to try Policy Tokens with your own agents, message me on LinkedIn.

Thank you to Alan, our customer and partner, for hosting Second Opinion and for organizing such great in-person events. Thank you to Louis and his team, to Thomas for his talk, and to AWS and Charline for organizing the evening with us.