An agent becomes operationally interesting when it can change something. That is also when an ordinary application mistake can turn into a sent message, an altered database, or a deleted file. Plan for incorrect output, malicious retrieved content, unavailable dependencies, and an operator making a tired decision.

This is a review checklist, not a security certification. We have not executed an end-to-end deployment, penetration test, or recovery drill for this guide. Each proposed control needs implementation and verification in your own environment. A checked box without observable evidence is still an assumption.

Define what each worker may do

Write a short contract for every tool: accepted input, permitted target, allowed operation, maximum scope, and approval requirement. A tool that retrieves an invoice should not also accept arbitrary SQL. A document summarizer should not inherit the publisher’s credentials just because both run in the same project.

Put authorization in the application or downstream service, outside the model’s judgment. Require explicit approval for consequential actions and bind that approval to the actual destination and payload. OWASP recommends reducing tool scope and checking authorization at the systems that perform actions in its excessive agency guidance.

Treat instructions found inside a web page, attachment, email, or tool result as content to analyze. They must not grant new authority. In a test environment, include a document that asks the agent to send data elsewhere, change a payment destination, or reveal a key. Record whether the boundary held, not just whether the model said it understood the rule.

Make failures small

Separate interactive requests from long-running jobs so an operator can stop a worker without taking down the entire interface. Give jobs identifiers and persist progress before side effects. After a timeout, check whether an external action happened before repeating it. A successful network retry can still create a duplicate business action.

Limit job duration, queued work, tool steps, output size, and concurrent execution. Place untrusted document processing and browser activity away from the main database credentials. Design an emergency stop that prevents new external actions while retaining the evidence needed to understand existing ones. Test that the stop works without the agent’s cooperation.

Inspect the container boundary

Run with the least privileges your workload requires and review every host mount. Access to the Docker daemon is powerful; a container with that access should not be treated as a harmless isolated worker. Docker describes this daemon attack surface. Its rootless mode can reduce some daemon and runtime risks, but does not replace application authorization or safe tool design.

Keep administrative interfaces private. Document which service accepts internet traffic and why. Pin a reviewed application release, record the image identity used in production, and keep the previous working release available. A restart policy helps a crashed process return; it does not prove the restored process is safe or healthy.

Give secrets a lifecycle

Separate development and production credentials. Scope keys to the intended project or service where supported, identify their owner, and write down how to revoke them. Keep secrets out of source control, image layers, screenshots, and support transcripts.

Docker Compose can grant secrets to individual services as mounted files. This reduces some accidental exposure compared with broadly available environment variables, but you must still secure the host’s source files and backup copies. Compose secrets are not a claim that every copy is encrypted. See Docker’s Compose secrets guide.

Before a rotation, identify all consumers. Afterward, verify both that the new credential works and that the old one no longer does. A changed configuration file is not proof that a long-running worker reloaded it.

Keep useful evidence without a content dump

For each action, log a task identifier, initiating identity, tool name, authorization result, target reference, timestamp, and outcome. Record a correlation identifier for related requests. Restrict access and retention, and review error paths that might capture payloads unexpectedly. OWASP’s logging guidance advises excluding or protecting access tokens, passwords, and sensitive data.

Choose alerts that lead to a decision: repeated denied actions, unusual outbound destinations, rapidly growing task counts, backup failures, and a queue that stops draining. Assign an owner and a response for each alert. Avoid an alert volume that trains everyone to ignore the channel.

Test recovery and rollback separately

A release rollback restores application code. A data restore restores a previous state. They are different procedures, especially after a database migration or an external message has already been sent. Write down which changes are reversible and which need a compensating action.

Vultr automatic backups cover the active instance filesystem, exclude attached block storage, and are stored in the same datacenter as the instance. Review the official backup scope; plan additional copies for data and failure scenarios outside it.

Define acceptable data loss and recovery time in plain language. Restore into an isolated environment, confirm that the application can read its data, and keep outbound jobs disabled during the exercise. Record the time taken, missing dependencies, and the person who can perform recovery. Finish the checklist only when those observations support your launch decision.