Securing AI Agents at Runtime: A Control-by-Control Guide

Secure an AI agent at the point where intent becomes an action. That means checking who is acting, which tool is requested, what arguments it received, what resource it will touch, and whether the result can be contained.

Prompt filters help, but they are upstream. Runtime security owns the final decision before a shell command, file write, API call, secret read, or network request produces a side effect.

*A useful runtime path has an enforceable decision before the side effect and evidence after it.*

1. Map the execution path

Start with one real workflow, not an inventory of security products. Draw the path from user or trigger to model, memory, retrieved context, selected tool, credentials, target system, and result. Mark every place where untrusted text can influence a privileged action.

An AI agent threat model should answer four concrete questions: what can initiate the run, what authority the agent inherits, which side effects are possible, and who can stop or reverse them.

The NIST AI Risk Management Framework is useful for governance and risk ownership. The OWASP Top 10 for LLM Applications supplies common failure language. Neither document configures the enforcement point for you.

2. Give the agent a distinct identity

Do not let an agent silently inherit a developer's broad session. Use a service identity or delegated identity that is specific to the workflow. Separate interactive testing from production credentials, and keep emergency or administrator roles out of the normal execution path.

Authentication says which principal is present. Authorization still has to decide whether that principal can call the requested tool with those arguments against that resource.

Short-lived credentials reduce exposure, but they do not fix an overbroad permission. A token that lasts ten minutes can still delete a production resource in ten seconds.

3. Build an allowlist around tools and destinations

List the tools the workflow needs. Deny the rest by default. For every allowed tool, constrain operations, parameter ranges, filesystem roots, network hosts, and data classifications.

Do not approve a generic shell tool because one command is useful. If the agent only needs to run tests, expose a narrow test action or constrain executable, working directory, environment, and arguments. If it only needs a vendor API, restrict egress to that host and block arbitrary redirects.

This is where policy enforcement becomes observable: the same request should produce the same decision under the same identity, resource, and policy version.

4. Inspect arguments and context at the last responsible moment

The tool name alone is not enough. read_file may be harmless for a public fixture and unacceptable for a credential store. A database query may be read-only until a parameter changes the target or calls a stored procedure.

Normalize arguments before evaluation. Resolve paths, decode URLs, expand aliases, and reject ambiguous encodings. Evaluate the final destination, not the string the model happened to emit.

For risky but legitimate work, use an approval state with a precise preview: requested action, resolved target, affected resource, identity, and reason. A generic “allow agent?” dialog trains people to click through.

5. Control side effects outside the model

Put hard boundaries in the host environment. Use read-only mounts, disposable workspaces, egress rules, process isolation, transaction limits, and scoped API permissions. These controls remain useful if a prompt or model-level rule fails.

Keep irreversible operations out of autonomous paths when a reversible equivalent exists. Create a branch instead of pushing to a protected branch. Move an object to quarantine instead of deleting it. Stage a deployment before changing production traffic.

6. Record decisions, not just model messages

An audit event should identify the actor, requested tool, normalized arguments or a safe digest, decision, policy version, approver if present, execution result, and correlation ID. Avoid dumping secrets or full sensitive prompts into logs.

Logs need an owner and a retention rule. Evidence that nobody reviews is storage, not control.

7. Test bypass and recovery

Create a small runtime test suite. Include an allowed action, an action outside scope, a path traversal, a redirected network request, a secret-like value, and a chained request where the first step is benign but the second is prohibited.

Test fail-open behavior. Disconnect the policy service, corrupt a rule, remove a hook, and exhaust an approval timeout. The intended failure mode must be explicit for each risk tier.

Then test recovery: revoke the credential, stop the run, isolate the workspace, restore the affected resource, and trace the event. Runtime security is incomplete if the team can block a request but cannot investigate what already happened.

Where AgentGuard fits

AgentGuard's public material describes Runtime Guard decisions before shell commands, file access, tool actions, network requests, secret access, and sensitive writes. It also describes component scans and different integration modes across supported clients.

That makes it worth testing near a supported agent-side control point. It does not replace cloud IAM, sandboxing, application authorization, or repository review. For Claude Code specifically, the documented pre/post tool-hook path can be evaluated alongside the broader steps in secure Claude Code tools.

Use a disposable workflow and retain the allow, approve, and block evidence. If the path spans several hosts or custom tools, book a runtime-control pilot around that exact architecture.