keepcalculator

06 Numbers and Powers

Monitor AI Agents for Unsafe Actions

Card No. 06·54641 · Updated · Standard formula, shown below

This guide shows you how to set up monitoring for AI agents so you can catch unsafe or unauthorized actions before they cause real damage. You’ll learn practical steps to log, review, and alert on agent behavior, using tools and processes that work with most current AI agent frameworks.

What You’ll Need

  • Access to the AI agent’s configuration and deployment environment (e.g., cloud console, API keys, or local server).
  • A logging system (e.g., stdout, a file, or a service like AWS CloudWatch, Datadog, or a simple database).
  • An alerting mechanism (email, Slack, PagerDuty, or a custom webhook).
  • Basic familiarity with your agent’s framework (e.g., LangChain, AutoGPT, or a custom implementation).
  • If the agent can execute code or access external systems, you need a way to capture those actions (e.g., API gateway logs, shell history, or a sandbox monitor).

Step-by-Step

  1. Define what “unsafe” and “unauthorized” mean for your use case. Write down specific rules: for example, “the agent must never delete files outside /tmp”, “must never send emails to external addresses”, or “must never spend more than $10 on API calls per day.” Make these rules concrete and testable.
  2. Instrument the agent to log every action. Add logging at every point where the agent takes an action—calling a tool, making an API request, reading a file, or sending a message. Include a timestamp, the action type, the input parameters, and the result. Use structured logging (JSON) so you can query it later.
  3. Capture the agent’s reasoning (if possible). Many frameworks let you log the chain of thought or the prompt/response pairs. This helps you understand why an action was taken, not just what happened. If you can’t log internal reasoning, at least log the final decision and the context that led to it.
  4. Set up a central log store. Send all logs to a single place where you can search and analyze them. This could be a simple file with rotation, a database, or a cloud logging service. Ensure logs are immutable (append-only) so they can’t be tampered with.
  5. Implement real-time alerting on rule violations. Create a monitoring script or use your logging service’s alerting features to trigger when a log entry matches a rule. For example, if the agent attempts to access a forbidden path, fire an alert immediately. Start with a small set of high-priority rules to avoid alert fatigue.
  6. Add a human-in-the-loop for high-risk actions. For actions that are risky but not entirely forbidden (e.g., sending a large payment, deleting a production database), require manual approval. Most agent frameworks support a “tool approval” hook where the agent pauses and waits for a human to confirm.
  7. Review logs regularly. Set a recurring schedule (daily or weekly) to manually inspect logs for patterns that automated rules might miss—like gradual escalation of permissions or unusual timing. Use dashboards to visualize activity.
  8. Test your monitoring. Deliberately trigger a few unsafe actions in a sandbox environment to confirm that your alerts fire and that logs capture everything. Do this after any change to the agent or the monitoring setup.
  9. Establish a response plan. Define what to do when an alert fires: who gets notified, how to pause or kill the agent, and how to roll back any changes it made. Keep this plan written down and rehearse it.
  10. Continuously update rules. As you observe new risky behaviors, add them to your rule set. Review the rules monthly and remove any that are no longer relevant.

Common Mistakes

  • Logging too little: Only logging the final output misses the intermediate steps that reveal intent. Log every tool call and API request.
  • Not logging the context: Without the prompt or the agent’s state, you can’t tell why an action happened. Always log the relevant context.
  • Alerting on everything: Too many alerts leads to ignoring them all. Start with a few critical rules and expand gradually.
  • Ignoring the human-in-the-loop: Relying solely on automated monitoring for high-risk actions is dangerous. Always require human approval for irreversible or expensive actions.
  • Not testing the monitoring: If you never test, you won’t know if your alerts work until a real incident occurs.
  • Storing logs insecurely: Logs can contain sensitive data. Protect them with access controls and encryption.

Tips

  • Use a unique request ID for each agent run so you can trace all logs from a single session.
  • Add a “dry run” mode to your agent that logs what it would do without actually doing it. This is great for testing.
  • Set up a separate log stream for security events, so you can monitor them separately from general logs.
  • Consider using a sandbox (like Docker or a VM) for the agent to run in, so even if it does something unsafe, the damage is contained.
  • Make your alert messages include the log entry and a link to the full context, so responders can act fast.

Troubleshooting

Alerts not firing? Check that the log format matches the rule’s pattern. Test with a known violation. If you’re using a regex, make sure it’s not too strict.

Logs are too large? Implement log rotation or sample only a percentage of low-risk events. Keep all logs for high-risk actions.

Agent bypasses monitoring? If the agent can execute arbitrary code, it might disable logging. Run the agent in a sandbox where it cannot modify the logging system, and use kernel-level audit logs.

Too many false positives? Tune your rules to be more specific. For example, instead of alerting on any file write, alert only on writes outside a specific directory.

Human approval slows things down? Use a timeout: if no approval within X minutes, the agent automatically cancels the action. Also, allow a “batch approval” for low-risk repetitive actions.

Frequently Asked Questions

Can I monitor an agent that I didn’t build myself?

Yes, if you can intercept its API calls or use a proxy. For third-party agents, you may only get logs from their platform—check what they expose.

What’s the minimum I should log?

At minimum, log every action the agent takes (tool calls, API requests) with a timestamp, the action name, and the parameters. Also log the agent’s final output.

How often should I review logs manually?

For a production agent, review at least daily. For a low-risk prototype, weekly is fine. The key is to look for patterns, not just alerts.

Can I use existing security tools for this?

Yes, many SIEM tools (like Splunk or ELK) can ingest logs and trigger alerts. You just need to format your agent logs to fit.

What if my agent uses a sub-agent that doesn’t log?

Ensure all sub-agents inherit the same logging configuration. If they don’t, treat them as black boxes and log their inputs and outputs at the parent level.

Is it legal to log everything the agent does?

It depends on your jurisdiction and the data involved. If the agent handles personal data, you may need to comply with privacy laws like GDPR. Consult a legal professional.

Related

Method: the standard formula for this calculation, rounded as each result states. See how the calculators work or report an error.

More cards in this drawer

The whole Numbers and Powers drawer →