AI Agent Security: A Practical Self-Hosting Checklist

An AI agent should have only the authority needed for its assigned task, enforced outside the model. A careful system prompt cannot compensate for unrestricted credentials, a writable host filesystem or a tool that executes whatever the model proposes. Start with the actions the application can actually perform, then constrain the route from untrusted content to those actions.

This checklist is for operators running their own agent applications. Its goal is to limit the damage an agent can cause, make misuse visible and give you a workable interruption and recovery path. Completing it is not a guarantee against prompt injection or compromise.

Map the path from input to action

Write down the inputs the agent reads, the data it retains, its available tools and the identities those tools use. Include retrieved pages, repository files, email, tool responses and persistent memory—not just messages typed into a chat box. These can carry instructions that conflict with the authorised task.

The Agent and tool layer needs a boundary between a proposed action and permission to execute it. A model can select a tool, but a separate application policy must decide whether that identity may perform that action on that resource. A tool being installed or discoverable is not authorisation to use it.

Use the following threat-to-control matrix as an ownership worksheet. Replace role labels with the people responsible for your deployment.

The same person may hold several roles. The important distinction is between controls: changing a prompt does not revoke an API credential, and patching a server does not narrow a tool's application permissions.

Treat retrieved content as data, not authority

A page saying “ignore earlier instructions” does not gain the authority of the operator who commissioned the task. Keep source content clearly delimited, validate structured inputs and prevent retrieved text or tool output from silently changing policies or privileged configuration.

Filtering suspicious text is useful but incomplete. The stronger boundary is action validation against the original authorised task, independent of instructions embedded in intermediate content. A second language model used as a guardrail can also be affected by prompt injection; it does not replace access controls or human approval.

Apply the same reasoning to memory. Scope persistent context to the appropriate user and session, control what can be written and retain it only as needed. Otherwise, an unsafe instruction can survive beyond the request that introduced it. Treat retrieved or remembered content as untrusted when it re-enters the workflow.

Separate credentials from permission to act

The Identity, observability and recovery layer connects access to accountability. Give each service identity the narrow permissions its role requires. Keep administrative identities separate from routine agent execution, and record which application consumes each credential so that you can withdraw access without guessing.

Keep secrets out of prompts, repositories, container images and logs. Deliver them through controlled runtime channels with restricted access. A secret available to a process can be used by that process: moving it into an environment variable does not make an overprivileged agent trustworthy. Limit the credential itself, not merely where it is stored.

For high-impact operations, separate proposal, policy evaluation, approval and execution. The approver should see the actual destination, operation and consequential parameters—not just the agent's summary of why the action sounds reasonable.

Bind the approval to the actor, tool, target, normalised parameters and expiry. A changed target or payload needs a new decision. Reject expired or reused approval artefacts, and stop a consequential action when its policy, approval or required audit validation fails. Do not let the agent mark its own proposal “approved”.

Approval also needs a retry boundary. Where an operation supports idempotency, use it to prevent repeated execution of the same request. Where its outcome is uncertain, reconcile what happened rather than treating another click or retry as harmless. A human approval should not become an unlimited licence to repeat an external effect.

Isolate the runtime without confusing the layers

The Host and network layer limits what the running process can reach. Run the agent as a non-administrative account. For a containerised deployment, avoid privileged mode and Docker socket access, restrict capabilities, retain security profiles and expose only the filesystem paths the task needs. Make input mounts read-only where writing is unnecessary.

Containers share the host kernel, so host and runtime patching still matter. Set explicit resource limits and separate administrative access from the application endpoint. Define inbound exposure and outbound destinations independently: an application can be privately reachable yet still send data through an unrestricted outbound connection.

Docker-published ports can bypass some host-firewall expectations, including UFW rules. Inspect the effective exposure rather than relying on a firewall label. A container boundary also cannot prevent misuse of an application credential deliberately made available inside it.

These controls reduce reachable resources. They do not decide whether an otherwise permitted API call serves the user's intent; that remains an application and tool-policy responsibility.

Protect state and logs without hiding failures

Retain the state needed to operate and recover the application, not every sensitive payload it encounters. Apply access and retention rules to sessions, memory, uploaded files and backups. Isolate users' data and protect stored sensitive content; a recoverable copy should not become an easier route to the same information.

Log enough to explain a decision: time, actor, task or correlation identifier, tool, target, policy version, outcome and reason. Include the approval reference for consequential operations. Avoid plaintext credentials, access tokens and unnecessary sensitive content. Sanitise untrusted values so that they cannot manufacture misleading log entries.

Restrict log access and protect records against tampering by the workload they describe. Infrastructure events alone cannot explain an application-level approval bypass. An operator needs to distinguish a model refusal, a policy denial, a failed tool and an action that actually completed.

Exercise denial and alerting before unattended use

Use an isolated environment that you own, with non-sensitive fixtures and no production credentials. Record the application version, effective operating-system account, service identity, available tools and permitted resources. These define the boundary being exercised—not a claim about every possible attack.

Configure a read-only fixture scope. Then ask the agent to perform a harmless write, such as creating a test note in that fixture. The expected result is no new note and an explicit denial event. A model's polite refusal is not enough: use your application's test harness to submit the same harmless proposal directly to the tool-policy boundary and establish that enforcement also rejects it.

Inspect the resulting event. It should identify the attempted operation, relevant identity, policy and denial reason without disclosing credentials. Exercise redaction with a nonfunctional marker in a designated sensitive test field, not a real secret. Send a test security notification through the configured alert route and establish that the responsible operator receives it.

An unexpected write, missing decision event, exposed marker or undelivered alert is a configuration failure to correct before expanding access. Save the observed result and repeat the exercise after the repair. Repeat relevant tests after material changes to prompts, tools, retrieval, memory, policies or model providers.

Detect abuse and interrupt work

Set execution boundaries for tool-chain depth, retries and model usage, with termination and escalation behaviour. Choose limits for your actual task rather than copying an unexplained workload budget. Alert on policy violations and abnormal behaviour, and make the operator's stop mechanism independent of the agent's willingness to comply.

Document how to stop workers and the triggers that can start new work. A stopped process and a revoked credential are different states. During an incident, preserve relevant decision records, contain execution and withdraw affected access; restarting the application alone does not remove the authority represented by a still-valid secret.

Rehearse revocation and recovery separately

Run this exercise against your isolated application, not production. Prepare a protected, application-consistent backup containing a known non-sensitive record. Retain the application version and configuration needed to interpret it, with recovery keys protected separately and available through the recovery process. Use the application's supported backup and restoration mechanism.

First, stop the test worker and its triggers. Revoke a dedicated low-privilege test credential at its issuing service. Repeat a previously successful harmless read with that old credential through the client's secure credential input. The expected outcome is rejection. Do not print the credential to prove which one you used.

Provision a replacement through the normal controlled secret channel and repeat the permitted read. Success with a replacement does not prove revocation: retain the old credential's rejection as a separate result. Record the credential identifier and access outcome, not its secret value.

Next, restore the known-clean backup into a fresh isolated target compatible with the recorded application version. Keep production connections and automatic actions disabled. Preserve the original backup and incident records; do not overwrite your only evidence while attempting recovery. Do not reintroduce compromised credentials or automatically replay pending writes.

The acceptance result has several parts: the known record is available, expected access restrictions remain effective, the old credential is rejected and no unintended action starts. Missing state or unexpectedly working old access is a failed rehearsal—not something to conceal with a successful service-start message.

Restoring application state does not undo an external action already performed. Reconcile affected operations separately and escalate ambiguous or irreversible effects. Record what was recovered, what remains unresolved and who owns the next decision.

Prioritise the checklist

Start with authority, then containment, visibility and recovery. Do not trade a missing control in one layer for a reassuring label in another. The useful result is an agent with explicit limits and evidence that your deployment enforces them—not an agent merely instructed to behave safely.

Our AI Agent VPS infrastructure provides a self-managed home for compatible agent applications. You own the application's installation, permissions, credentials, monitoring, updates and recovery. Keep those operational responsibilities explicit when deciding how to run it.