AI Agent Access & Safety
Last updated: June 12, 2026
DeployMill exists so you can hand an autonomous AI agent the keys to production and sleep at night. That is a strong claim, so this page makes it precise: what it actually means to connect an agent, exactly what a connected agent can and cannot do, which guardrails enforce that boundary in the platform itself (not in a policy document), and what remains your responsibility as the human who owns the account.
This is the document to hand your security team before you connect an agent. For the broader division of duties between you and us, see Shared Responsibility.
What "connecting an agent" means
You connect an AI coding agent (Claude, Codex, or any MCP-compatible client) to DeployMill over the Model Context Protocol (MCP). Mechanically:
- The agent authenticates via OAuth, as you. Your MCP client walks through a standard OAuth flow in your browser. You sign in and consent. There are no static API keys to mint, paste into a config file, or leak.
- Tokens are short-lived and workspace-scoped. The access token the agent receives is bound to one workspace (organization). It expires and must be refreshed. It cannot be widened after issuance, and it cannot reach any other organization's apps or data.
- The agent acts on your behalf. Everything it does is performed under your identity, recorded in the audit trail as such, and bounded by your effective permissions in the workspace (your role's defaults plus any per-member grants or revokes). The agent never holds more privilege than the human who connected it.
Once connected, the agent drives the full deploy lifecycle through typed MCP tools: creating and importing projects, deploying, spinning up preview environments, attaching domains, managing env vars, binding secrets, provisioning databases and object storage, rolling back, and reading logs and health.
Capability table
| Capability | Can the agent do it? | Guardrail |
|---|---|---|
| Create projects and GitHub repos | Yes | Scoped to your workspace; recorded in the audit trail |
| Push and read source files | Yes | Short-lived, repo-scoped git credentials, never the platform's own GitHub credentials |
| Deploy to production | Yes | Health-gated rollout with automatic rollback on failure |
| Create and destroy preview environments | Yes | Fully isolated per preview: copy-on-write database branch, fresh volume and bucket, so previews cannot touch production data |
| Attach and detach domains | Yes | Scoped to your workspace's apps; TLS provisioned by the platform |
| Set and delete environment variables | Yes | Plain (non-secret) values only travel this path; audited |
| Bind secrets to apps | Yes, by name only | The agent references a secret by name. The tool surface never returns the value, and it is never echoed into the agent transcript |
| Read secret values | No | Zero-readback vault: no tool exists that returns a secret value, to the agent or anyone else |
| Enter or change secret values | No | Human-only, via a single-use browser hand-off |
| Provision databases and object storage | Yes | Provider-neutral interfaces; credentials are injected server-side, scoped per app |
| Roll back a deployment | Yes | Rollback targets are prior known-good releases; audited |
| Read logs and health | Yes | Read-only; scoped to your workspace's apps |
| Preview a change before applying it | Yes | Dry-run reconcile: diff → plan → apply, so the agent (and you) can see what would change before it does |
| Access infrastructure credentials (kubeconfig, registry tokens, database/storage/vault keys) | No | Backend credentials never appear in any tool response, and they stay server-side, always |
| Reach another organization's apps or data | No | Hard per-organization tenant isolation; tokens are workspace-scoped |
| Manage members, roles, billing, or SSO | No | Account and org administration is deliberately human-driven, so these are not agent tools |
| Contact support | No | Support is human-first and email-only — /account/support points you at a monitored mailbox |
The guardrails in detail
These are enforced in the platform's architecture, not by asking the agent nicely.
The agent never sees a secret value
Secrets enter DeployMill through a single-use browser hand-off: when a secret is needed, a human opens a one-time link and types the value directly into DeployMill, where it is stored encrypted with AES-256-GCM. The value never passes through the agent, never appears in a tool response, and is never echoed into the agent's transcript or context window. The agent can do exactly one thing with a secret: bind it to an app by name. The plaintext leaves the vault only when injected server-side into the app's runtime environment.
This matters because agent transcripts are not a safe place for secrets. They get logged, replayed, summarized, and shared. DeployMill is designed so a secret value structurally cannot end up there.
The agent never escapes its workspace
Tenant isolation is per-organization and enforced on every tool call. The OAuth token the agent holds is scoped to one workspace. There is no parameter, flag, or identifier that lets a call cross into another tenant's apps, databases, secrets, logs, or domains. A compromised or confused agent in your workspace is still confined to your workspace.
The agent never holds infrastructure credentials
The credentials that actually run the platform (the Kubernetes kubeconfig, container-registry push tokens, database keys, object-storage keys, and the secrets-vault key) stay server-side, full stop. No tool response ever contains them. When the agent legitimately needs git access to your repo, it receives short-lived, repo-scoped clone credentials minted for that purpose, never the platform's own source-provider credentials. The blast radius of a leaked agent transcript is therefore bounded by design: there is nothing infrastructure-shaped in it to leak.
The agent can't silently break production
Three mechanisms work together here:
- Preview isolation. Every preview environment gets a copy-on-write database branch and a fresh volume and bucket. The agent can experiment freely in a preview without any path to production data.
- Health-gated deploys with auto-rollback. A production deploy must pass its health gate before traffic shifts. If it fails, the platform rolls back automatically. The agent cannot leave production serving a broken release by walking away mid-deploy.
- Dry-run reconcile. Configuration changes support a diff → plan → apply flow, so the agent can compute exactly what would change (and you can review it) before anything is applied.
Everything is on the record
Every action a connected agent takes is written to an append-only, attributable audit trail: what was done, to which resource, when, and under whose authority. There is no agent action that bypasses it. If you ever need to answer "what did the agent do last Tuesday?", the answer is complete and tamper-evident.
What stays human-only
Some things are deliberately not on the agent surface, and never will be:
- Entering secret values. Only a human, through the single-use browser hand-off, can supply or change a secret's value.
- Account and organization administration. Members, roles, invites, billing, and SSO configuration are managed by humans in the dashboard (with a full API for automation you control, but no agent tools). Agents ship apps. People run workspaces.
- Support. Support is email-only: the dashboard's support page points you at a monitored mailbox. People contact support, not agents.
Your responsibilities
The guardrails bound what an agent can do. What it chooses to do within those bounds follows from your instructions, and you, the human account owner, are accountable for it. Concretely:
- Review what the agent ships. The agent acts on your instructions and your credentials. A deploy it performs is your deploy. Use previews and dry-run plans to inspect changes before they reach production.
- Don't instruct it to misbehave. Anything the agent deploys is subject to the Acceptable Use Policy, exactly as if you had deployed it by hand.
- Secure your side of the connection. Keep the machine running your agent client secure, protect your DeployMill sign-in, and treat the agent's session like the privileged session it is. DeployMill bounds the blast radius of a compromised agent. It cannot prevent the compromise of your own device.
- Mind what you put in front of the agent. Prompt-injected or untrusted content you feed your agent can steer its behavior. The guardrails above limit the damage (no secrets, no cross-tenant reach, no infra credentials, auto-rollback), but the first line of defense is your own agent hygiene.
Revoking an agent's access
You can cut an agent off at any time:
- Open your account dashboard and revoke the connected MCP client's access under your account's connected-applications settings.
- Because tokens are short-lived, revocation takes effect as soon as the current token expires, and refresh is denied immediately.
- If you suspect your account itself is compromised (not just the agent), change your sign-in credentials and contact [email protected].
Everything the agent did up to revocation remains in the audit trail for your review.
Data & privacy
A connected agent operates on your own data (your repos, your apps, your databases, your logs) inside your own workspace. Connecting an agent does not grant DeployMill any new rights to your data, and it does not expose your data to other tenants or to the agent vendors' training pipelines via DeployMill. What your agent vendor does with your conversation transcript is governed by their terms, so choose your agent accordingly.
For what DeployMill itself stores and how, see the Privacy Policy. For which third parties data can reach in the default managed stack, see Subprocessors.
Reporting a concern
- Security vulnerabilities, including anything that lets an agent exceed the boundaries on this page: [email protected], per the Vulnerability Disclosure policy. A way for an agent to read a secret value, cross a tenant boundary, or obtain infrastructure credentials is a critical finding and treated as such.
- Questions about this page or agent behavior: [email protected].
- Privacy questions: [email protected].