An AI agent on a production server: what I let it do and what I do myself

In one October week, six companies wrote about how to let an AI agent into production systems without surprises. Vercel showed the plan-and-scopes scheme for its agent, Docker locked the agent in a sandbox, Supabase gave it the production database read-only, GitLab started an agent log, Auth0 took tokens apart, and Workato told why a legal company doesn't give the model full access to Salesforce. If you have your own server, CRM and phone system, sooner or later someone will suggest “let the agent fix it itself.”

What came out and from whom

On October 23, Vercel described how its agent works with production. A request like “fix the deploy” doesn't say in advance which actions will be needed, so the agent first investigates the problem with read-only permissions and then proposes a plan: which tasks it will perform and which permissions (scopes) it needs. The plan is approved as a whole, and a short-lived token is issued for it: base read permissions plus the approved ones. The agent runs as a Vercel app on the user's behalf and can't get more permissions than the user has. An operation outside the token is rejected by the API, even if the model considers it necessary.

Docker on October 21 showed Docker Sandboxes paired with the BAND platform. The agent runs in an isolated micro-VM with its own kernel, file system and network, and only outbound connections leave it. Keys stay on the host: the sandbox inserts them into outgoing requests, and the agent sees placeholders.

Supabase on October 20 released a kit for checking a production project with an agent: Health, Security, Performance and Resources prompts, plus a query_logs tool for read-only SQL over the logs. Two pieces of advice from there I'd repeat to everyone: connect the MCP server with the read_only=true flag, and for scheduled runs allow only read tools ahead of time, because a scheduled run can't stop and ask. The prompts tell the agent to ignore instructions it finds in the logs.

GitLab on October 20 opened a beta of its AI Governance dashboard for Premium and Ultimate: which agents ran, who ran them, which projects they touched. Event storage is off by default, and external agents connect through glab govern setup.

Auth0 on October 20 explained why the usual client registration breaks down with agents: permissions used to be assigned by hand at registration, while an agent needs them on the fly and along a chain of calls. Auth0's answer is a strict API mode with an explicit grant for each client, registration by metadata (CIMD) and token exchange under RFC 8693, so the token shows which user allowed the action and which agent is acting on their behalf.

Workato on October 21 published the story of Relativity, a legal company with almost 2,000 people. Its applications architect says access control in vendor MCP servers shows up months after release, so the company built its own MCP servers with role-based access and service accounts; the first one, for Jira Data Center, is running in production.

Example: “fix the phones” at a service company

Take a service company with its own PBX, CRM and website. On Friday evening, calls stop turning into leads, and an employee writes to the agent: “fix it.” With full access, the agent can restart the phone system, change the routing and, while it's at it, “clean up” duplicates in the CRM that weren't duplicates. With read access, it looks at the logs, compares the configuration with the last working one and says what changed. A person makes the decision.

The agent's permissions should follow the task. Read access can be granted more often, although even that shows the agent your customers' data. Write access only once you can see exactly what it's about to write.

How it works for me

Since 2021 I've been the technical partner of a PDR company in the US: the server, the network, our own PBX with AI call analysis, document parsers and an internal API are on me. Security questions at the company come to me. Since 2022, when we got our own server, there have been no serious failures that needed a recovery.

AI helps me with routine work, testing and debugging, and it has sped up my development several times over. My line runs where Vercel's does: the agent prepares the change, and I apply it on the production server after checks. Architecture and the fundamental decisions I make myself. I don't have an agent that pushes a fix to a PBX carrying customer calls on its own. I haven't tried the products from these stories on my own servers, so I'm talking about the schemes.

What I would do

Set up a separate account for the agent with read-only permissions: logs, configuration, the database in read-only mode. That's what Supabase recommends.

Write down which actions the agent proposes and which it performs itself. Restarting a service, migrating a database, changing call routing and sending anything to customers are on my list under “proposes, a person performs.”

Keep keys away from the agent, on the host or in a secrets manager, the way the Docker sandbox does.

Keep a log: who started the agent, what it read, what it proposed, what was applied. In a small company a plain spreadsheet is enough.

Check logs and emails for injected instructions: an agent that reads other people's text will one day read “delete everything” there.

Related reading

On rules, statuses and permissions for people and AI: the article Business logic: rules, statuses and permissions. Services: AI in a process where the result can be verified and infrastructure that can be released and restored. All the work with the PDR company is in the case study Technical partner to a PDR company in the US since 2021. Nearby are my reviews on single-run keys instead of permanent ones and on sandboxes for agents, and earlier I looked at how to review AI code. If you have a server you'd like to let an agent near, tell me what runs on it and what should stay with a person. Discuss your task.