CloudTrail for AI Agents

tl;dr — TrailTool is in early access at trailtool.io. It pre-aggregates CloudTrail into an access graph so AI agents can answer security questions without drowning in raw logs. Built for IAM least privilege workflows, incident investigations, and anything that needs fast CloudTrail analysis.

For both detection and prevention, security teams need to answer questions about AWS IAM access. You may be investigating a malware alert and wonder if local credentials have been abused. You may be crafting least privilege IAM policies and need a rough sketch of permissions based on usage.

The first step is building CloudTrail analytics. CloudTrail (and S3) is where AWS audit logs live, and while turning them on is straightforward enough, making them useful can be challenging. SIEMs or AWS offerings (CloudTrail console, CloudTrail Lake) manage the infra to provide full visibility, but there are tradeoffs:

  • Volume is big, so queries can be expensive/slow
  • Structure is abstract, so queries are complex
  • Records are verbose, so results can be hard to parse

As security workflows incorporate AI, the limitations of treating these logs as big unstructured blobs until query time (i.e. “data lake”) can impede and overwhelm AI agents. Slow loops, brittle command syntax, and context-busting results waste tokens and don’t lead to high confidence answers.

TrailTool solves this by pre-aggregating CloudTrail events into entities: People, Sessions, Roles, Services, Resources. Human operators and AI agents get concise, actionable answers without the fuss.

Why Pre-Aggregation Matters

With vanilla CloudTrail, answering questions like “did contractor@company.com update this S3 bucket in the last 30 days?” could mean sifting through TBs of logs, toiling with custom queries, and correlating role assumptions by hand. TrailTool pre-aggregates logs so answers to your most important questions are a click or API call away.

TrailTool groups CloudTrail events and aggregates duplicate information to build an access graph: People to Sessions, Roles to Services/Resources. This information is lossy, and for forensic-level detail, you want the source of truth in the data lake. But it can super valuable to elide huge amounts of data to say “has this access happened or not”.

The idea is that TrailTool works alongside CloudTrail Lake and your SIEM. Use CloudTrail Lake for deep analysis and legal holds, SIEMs for alerting and dashboards. TrailTool shines for fast, ad-hoc investigations and pipelineing audit data into agent summaries.

Example - coding agent for least privilege policies

Generating least privilege policy from CloudTrail logs is non-trivial, but tools like IAM Access Analyzer and iamlive have mapped out this path. These approaches will likely get you a policy, but shipping it is an exercise left to the reader. What happens when that new restricted role throws AccessDenied errors during an incident?

Tools like IAM Policy Autopilot use code to generate permissions, so focus on service roles rather than human access patterns. This leaves out a big surface area.

I’ve heard this referred to as role engineering: the ongoing process of refining roles as your organization changes and engineers need new permissions. Automated tools can generate a policy, but what happens when someone uses the “break glass” admin role and you need to understand whether their actions should inform the next policy update?

Imagine a new process:

  • You ask your coding agent to generate the latest least privilege IAM policy for PowerUserEngineer IAM role
  • A tool returns a generated IAM policy based on the last 30 days
  • The coding agent updates your existing Terraform to incorporate those IAM policy changes and generates a PR
  • You review, merge, deploy
  • Someone tries to click on the shiny new AWS service “Create” button using that role and gets “Access Denied”
  • A background agent reaches out to the user via Slack bot with an apology and link to “break glass” access approval workflow, asks for more info to understand intent, then drafts a PR granting the new permissions with context for security review
  • Another background agent tracks whether the approved “break glass” access was used as intended by matching the user’s narrative with the AI sessions summary

With TrailTool, all of the context to power this workflow lives in MCP land, eliminating the copy/paste, bash scripting, and context loss that makes AI role engineering tedious.

Role engineering, as with all developer tooling challenges, is about the conversation, not a one-time change. You need visibility into what’s being used, what’s being denied, and what people are actually trying to accomplish. By pre-aggregating CloudTrail into entity relationships (People, Sessions, Roles, Resources) and exposing it through MCP, TrailTool lets agents participate in that conversation, increasing the racheting speed of your least privilege efforts.

Try TrailTool

TrailTool is in early access. Sign up at trailtool.io to get started with the hosted version, or reach out if you want to self-host.

If you’re building AI-driven security workflows and CloudTrail analytics are slowing you down, let’s talk. Connect on LinkedIn or Mastodon.

Back to Blog