Securing AI Agents in Production: A Practical Checklist

AI agents combine three things security teams watch closely: credentials, outbound network calls and actions taken without a person in the loop. A prototype can get away with a model key in an environment file. A production agent cannot. The checklist below is ordered roughly by how often each gap shows up in real reviews.

1. Keep secrets out of code and manifests

The agent's manifest should list the names of the secrets it needs, never their values. Values belong in an encrypted store, scoped to a project and environment, and delivered to the runtime at deploy time.

• Encrypt values at rest with a modern authenticated cipher such as AES-256-GCM.
• Never display a secret again after it is saved. Replace, do not reveal.
• Use different values for development and production.
• Keep secret values out of logs and audit records entirely.

spec:
  secrets:
    - name: OPENAI_API_KEY
      reference: support-triage/openai
    - name: DATABASE_URL
      reference: support-triage/database

2. Prefer short lived cloud credentials

The connection between your deployment tooling and your cloud account is a high value credential. Use the narrowest option each provider supports. On AWS that means a cross-account IAM role with an external ID instead of long lived access keys. On Azure it means a Microsoft Entra sign-in rather than a pasted password or key. OAuth is the right choice where the provider offers it.

3. Authenticate every caller with scoped keys

If other applications call your agent, give each one its own key. Scope keys to the action they need, limit them to a single agent where possible, set an expiry and store only a hash. Our article on designing API keys for AI agents covers this in depth.

4. Isolate tenants at the data layer

If your platform serves more than one team or customer, every query must filter by the owning organization, and the check must happen on the server, not in the interface. Requests for another organization's resources should answer not found rather than forbidden, so they do not reveal that the resource exists.

5. Apply least privilege to people

Not everyone who reads deployment status should be able to deploy, and not everyone who deploys should manage billing or approve production. Fixed roles with clear permissions are easier to review than ad hoc grants. BeansHost uses seven built-in roles, from Organization Owner to Viewer, and the operations page lists what each one can do.

6. Minimize what you store about runs

Prompts and responses often contain personal or confidential data. The safest record is one that never held it. Record status, duration, provider, error category, byte counts and correlation IDs, and leave content capture off unless there is a specific, approved reason to turn it on. See monitoring AI agents without storing prompts.

7. Protect the edges

• Throttle sign-in attempts per address and per account.
• Rate limit API traffic per address, per user and per plan.
• Cap request body sizes. A 1 MiB limit on agent calls stops many abuse patterns.
• Bind OAuth state to the browser that started the flow.
• Send Content Security Policy and Strict Transport Security headers on any console.

8. Keep an append-only audit trail

When something goes wrong, you need to know who did what and whether it worked. Write privileged actions to a log that cannot be edited, include failed attempts, and make it exportable. The details are in governing AI agents with audit logs and approvals.

9. Fail closed for production

If a release needs an approval and the approval system cannot answer, the safe default is to stop. A production deployment that proceeds because a check timed out is a control that only works on good days.

The checklist

1. Secrets encrypted, scoped per environment and never shown again.
2. Short lived or role based cloud credentials.
3. Scoped, expiring, hashed API keys per caller.
4. Tenant isolation enforced on the server.
5. Fixed roles following least privilege.
6. Metadata only run records by default.
7. Rate limits, size limits and sign-in throttling.
8. An append-only audit log including failures.
9. Production gates that fail closed.

Read how BeansHost applies these controls on the security page.