How to Secure AI Agents Before Production Access

An AI agent becomes a security concern when it can turn model output into an external effect. Reading a file, querying a customer record, sending an email, opening a pull request, changing cloud infrastructure, or starting a payment all cross that boundary. The security objective is not to make the model incapable of error. It is to make sure an error, manipulation, or compromise cannot exceed a deliberately small and observable authority.

This article is a broad production baseline. It covers identity, tool permissions, data boundaries, secrets, approvals, isolation, logging, response, and testing. Prompt injection belongs in that baseline, but it is not the whole security model. A separate deep treatment can examine prompt injection as an authorization problem; the immediate priority here is the complete control stack required before any agent touches a real system.

Begin with authority, not prompts

List every external effect the agent can cause and every data source it can reach. For each one, record:

the calling human or workload identity;
the agent or runtime identity;
the tool and downstream service identity;
allowed actions and resources;
important parameter limits;
whether the action is reversible;
approval and separation-of-duties requirements;
the evidence that must be recorded; and
how access and in-flight work can be stopped.

If the team cannot complete that inventory, the agent is not ready for write access. It may still operate in research, draft, simulation, or shadow mode while the boundaries are clarified. Bluegrass Cloud’s cloud security and governance work can help define identity, logging, policy, shared responsibility, and remediation for an agreed environment.

Threat-model the entire agent path

A conventional application receives input, applies code, and calls services. An agent adds a model that can interpret natural language, choose tools, incorporate retrieved content, and iterate. That creates several interacting attack surfaces:

Direct input: a user intentionally asks for an unauthorized or unsafe action.
Indirect input: a document, web page, ticket, message, or tool result contains instructions intended to steer the model.
Tool misuse: an allowed tool is invoked with a dangerous target, parameter, sequence, or frequency.
Identity confusion: the system loses track of which user, tenant, or agent is responsible for an action.
Credential compromise: secrets or tokens are exposed in context, logs, configuration, or a connected server.
Data leakage: the model or a tool sends more information than the requester is authorized to receive.
Memory poisoning: malicious or incorrect information persists and influences later runs.
Supply-chain compromise: a model, dependency, plugin, MCP server, prompt package, or tool changes behavior.
Resource abuse: loops, tool chains, or recursive agents consume budget, quota, or capacity.
Audit failure: operators cannot reconstruct a decision or distinguish a model proposal from an executed action.

OWASP’s agentic threat guidance and NIST’s work on agent identity both reinforce a central point: an agent is not just a chat interface. It is a software actor with data, identity, tools, and consequences. Threat models should be refreshed whenever those capabilities or credentials change, even if the user interface does not.

Give every actor a distinct identity

A production record should be able to answer three questions independently: Who requested the work? Which agent runtime handled it? Which identity performed each downstream operation?

Do not collapse those into one powerful service account. Authenticate the human or calling workload at the application boundary. Give the agent runtime its own workload identity. Give tools separate execution identities based on their responsibility. Where the downstream platform supports it, preserve the end-user identity or an explicit, constrained delegation instead of silently converting every request into the same administrator.

Prefer short-lived credentials obtained at run time. Bind them to the intended audience, tenant, action, and duration where the platform permits. Do not let the model choose a role ARN, tenant ID, account, or credential scope from arbitrary text. Trusted application code should derive those values from authenticated context and policy.

NIST’s 2026 concept work on software-agent identity highlights identification, authorization, auditing, and non-repudiation as practical challenges. Treat these as application requirements now rather than waiting for one universal “agent identity” standard.

Make least privilege concrete at the tool boundary

“The agent can use GitHub” is not a permission definition. “The agent can read issues in repositories A and B and open a pull request from a namespaced branch, but cannot merge, change settings, create secrets, or administer teams” is closer.

Design tools around business intent rather than exposing a general API client or shell:

Prefer create_draft_change_request over http_request.
Prefer query_incident_logs with fixed sources and time bounds over unrestricted log access.
Prefer schedule_approved_maintenance over arbitrary infrastructure commands.
Separate reads, drafts, writes, destructive actions, and administrative actions.

Validate tool parameters against a strict schema, then apply policy using trusted identity and current resource state. Limit list sizes, time ranges, file paths, URLs, amounts, regions, and allowed transitions. Reject unknown fields. Resolve canonical resource identifiers before authorization to prevent path, alias, or case tricks.

Keep deterministic operations deterministic. Amazon Bedrock AgentCore’s security guidance explicitly warns against routing deterministic operations through the model runtime. If a service can validate and perform an operation directly after authorization, the model does not need to sit in the execution path.

Put authorization outside the model

System prompts and tool descriptions guide behavior; they are not enforcement. A model can misunderstand them, a new input can conflict with them, and a tool description can be misleading. The allow or deny decision must be made by code or a policy engine that the model cannot rewrite.

Evaluate each tool call using at least:

requesting principal and tenant;
agent and tool identity;
action and canonical target resource;
normalized arguments;
current environment and resource state;
risk tier and approval status; and
time, rate, and budget limits.

Default deny is easier to reason about than a growing list of exceptions. AWS AgentCore Policy, for example, can evaluate Cedar policies at a gateway boundary so tool authorization is deterministic and external to the agent implementation. The same architectural principle applies on other platforms.

Treat every external content source as untrusted

Prompt injection can arrive through content the user never typed: a web page, repository file, support ticket, email thread, document, calendar event, or tool response. The text may tell the model to ignore prior instructions, reveal data, or call another tool. Delimiters and warnings can help the model distinguish data from instructions, but they do not create a security boundary.

Reduce exposure by giving the agent only the content it needs, labeling its provenance, stripping active or irrelevant material, and preventing untrusted content from directly selecting credentials or policy. Validate the agent’s proposed action after it has processed the content. OpenAI’s official agent safety guidance similarly recommends treating prompt injection and private-data leakage as persistent risks and constraining what connected tools can access.

The right question is not only, “Did the filter detect an injection?” It is, “If the model follows a hostile instruction, what can it actually read, send, or change?” That answer should still be acceptably bounded.

Control data before it reaches context

Apply authorization during retrieval, not after it. A vector search or knowledge base should return only records the requesting principal may access. Do not retrieve an entire multi-tenant dataset and instruct the model to hide unauthorized rows.

Minimize fields, result count, and retention. Tag content with source, tenant, classification, and timestamp. Prevent sensitive categories from entering model context unless the use case explicitly requires them and the selected service configuration is approved for that data. Review whether prompts, outputs, embeddings, traces, and cached context are stored, in which Region, for how long, and who can read them.

For outbound data, inspect both destination and payload. An agent with web access and access to secrets has a straightforward exfiltration path. Use network egress allowlists, private endpoints where appropriate, response-size limits, and data-loss controls at enforceable boundaries. Do not ask the model to remember which domains are trusted.

Keep secrets unavailable to the model

Use workload identity instead of static keys whenever possible. Store unavoidable third-party secrets in a managed secret store and let the narrow tool runtime retrieve them. The agent should call “send through approved ticketing API,” not receive the API token.

Prevent secrets from entering:

system or developer prompts;
tool descriptions and sample arguments;
repository instruction files;
retrieval indexes;
model invocation logs and traces;
exception messages; and
approval screens or generated summaries.

Scan for likely secrets before sending context to a model and before persisting telemetry. Rotation is still required: an agent system adds more pathways through which a secret could leak.

Design approval gates for informed consent

Approval is useful when it is specific. Show the exact action, target, significant parameters, source of the request, evidence, expected effect, and rollback option. An approver should not have to trust a paragraph written by the same model requesting permission.

Store an immutable proposal with an expiration and single-use identifier. Authorize the approver separately. Recheck policy and resource state immediately before execution. Any material change to the proposal invalidates the approval.

Use risk tiers to avoid both extremes:

Tier 0: read approved public or low-sensitivity data.
Tier 1: create drafts or reversible changes in an isolated environment.
Tier 2: perform bounded, externally visible, or moderate-impact actions after approval.
Tier 3: perform privileged, destructive, financial, regulated, or hard-to-reverse operations only through normal high-assurance controls, with the agent limited to recommendation where appropriate.

An AI solutions and implementation engagement should define these approval and operating responsibilities before production access is granted.

Sandbox execution and restrict the network

If the agent can run code or shell commands, isolate it from the operator’s workstation and from production by default. Use a disposable container, virtual machine, or managed sandbox with a read-only base, non-root user, bounded CPU and memory, limited writable paths, and no ambient cloud credentials.

Mount only the required repository or working data. Start with network access denied, then allow specific destinations through a controlled proxy if the task needs them. Separate build-time dependency access from run-time application access. Destroy the environment after the task and preserve only reviewed artifacts and required audit evidence.

Sandboxing contains some consequences; it does not validate intent. A sandbox with a production token can still damage production. Pair isolation with scoped credentials, tool policy, and approval.

Log actions without creating a new data leak

An audit record should connect:

authenticated requester and tenant;
request and correlation ID;
agent, model, prompt, policy, and tool versions;
retrieved source identifiers, where appropriate;
proposed tool calls and normalized arguments;
authorization and approval decisions;
executed calls and downstream response identifiers; and
final status, corrections, and stop reason.

Do not indiscriminately log full prompts, hidden reasoning, customer records, credentials, or complete tool output. Record the evidence needed to reconstruct control decisions, redact sensitive values, encrypt storage, restrict readers, and set retention. Immutable or append-only security events are useful for high-impact actions.

Monitor for unusual tool sequences, repeated denials, new destinations, cross-tenant access attempts, high loop counts, token spikes, approval bypass attempts, and changes to agent configuration. Integrate alerts with the existing incident process rather than creating a separate console no one watches. Bluegrass Cloud’s managed cloud operations can include agreed monitoring and documentation for supported workloads.

Build kill switches at more than one layer

A production team needs to stop the system without asking the model to cooperate. Useful controls include:

disable new agent requests at the API layer;
revoke or deny runtime and tool identities;
disable write tools while preserving read-only diagnosis;
stop queued and long-running jobs;
block outbound network access;
rotate suspected credentials; and
pin or roll back a model, prompt, tool, or policy version.

Test these controls. A configuration flag that no operator can locate during an incident is not a kill switch. Document who may activate it, how active work is handled, and how service returns safely.

Test the controls, not only the model

Build an evaluation suite that includes legitimate work, malformed input, unauthorized requests, indirect prompt injection, poisoned retrieval, tool errors, stale approvals, cross-tenant identifiers, secret-like strings, excessive loops, and unavailable dependencies. Verify that the correct layer rejects each scenario.

Run conventional security testing too: dependency and container scanning, API authorization tests, IAM review, network verification, secret scanning, logging review, and incident exercises. Red-team the agent as a system. A model that refuses a malicious sentence while an API accepts an unauthorized resource ID is not secure.

Roll out authority progressively:

offline evaluation;
read-only shadow operation;
drafts with human review;
reversible sandbox actions;
bounded production actions with approval; and
limited auto-execution only after evidence supports it.

The minimum production baseline

Every caller, runtime, and tool has an attributable identity.
Authorization is deterministic, external to the model, and default-deny.
Tools are narrow, schema-validated, resource-scoped, and separated by risk.
Retrieval filters unauthorized data before it reaches model context.
Secrets stay in managed stores or workload identity, not prompts.
Untrusted content cannot directly select authority or execution targets.
High-impact actions require specific, expiring, revalidated approval.
Code execution and network access are isolated and limited.
Audit records link request, decision, authorization, execution, and outcome.
Budgets, timeouts, rate limits, stop conditions, and tested kill switches exist.
Security regression tests run when models, prompts, tools, policies, or data sources change.

Security is the architecture that remains when the model behaves incorrectly. If you are preparing to connect an agent to real cloud or business systems, contact Bluegrass Cloud with the intended tools, data, identities, and production consequences.

How to Secure AI Agents Before They Access Real Systems