Burn: AI Agent Security

Inspiration

AI agents are becoming more autonomous, handling everything from customer information to internal databases and sensitive API credentials. But this creates a security problem that we felt wasn't being addressed enough.

Revoking an AI agent doesn't revoke what it already saw.

If an agent gets compromised through prompt injection or another attack, shutting it down doesn't necessarily solve the problem. It might have already encountered API keys, credentials, or other sensitive information that remain valid afterward.

We realized that most security solutions focus on detecting threats or blocking requests, but detecting an attack is only half the problem. What happens after an agent is compromised?

That's what inspired us to build BURN, an AI agent security platform focused on detecting credential exposure, containing compromised agents, and helping teams recover without shutting down their entire AI workforce.

What it does

BURN gives developers and security teams visibility and control over the credentials their AI agents can access.

Every agent receives its own identity, permissions, and credentials wherever possible. As agents interact with tools, BURN tracks which credentials they encounter through an exposure ledger.

Our system combines multiple security layers:

Agent identity and isolation: Each agent has its own credentials and authenticated sessions, reducing the risks of sharing access across an entire fleet.

Credential exposure tracking: BURN records which agents encountered sensitive credentials without storing their raw values in the exposure ledger.

Real-time leak prevention: An outbound security proxy detects and blocks recognizable credential leaks, including several encoded forms.

One-click containment: Operators can revoke a compromised agent's session, rotate credentials it exclusively owns, and flag shared credentials for review.

Incident investigation: Security teams can inspect activity logs and AWS CloudTrail records to understand the potential impact of a compromised agent.

Real-time security notifications: Alerts and containment updates are delivered through Slack, Discord, Telegram, and email.

One of BURN's most important features is selective containment. Instead of shutting down every agent or blindly rotating every credential, BURN focuses on the affected instance while preserving access for unaffected workers.

How we built it

We built BURN using AWS services and a modular architecture designed around agent security.

Our AI agents use Amazon Bedrock and Strands Agents, while Amazon Cognito manages session identities and authentication.

Amazon Bedrock AgentCore Gateway acts as the security checkpoint for agent tool calls. Request interceptors verify permissions and session status, while response interceptors identify credential exposure and record it in Amazon DynamoDB.

We built a credential-management system using AWS Lambda, IAM, and AWS Secrets Manager to issue and rotate credentials. The exposure ledger uses credential fingerprints rather than storing plaintext secrets.

For outbound protection, we developed an egress proxy that inspects agent traffic and blocks recognizable credential leaks before they reach unauthorized destinations.

We also implemented session-specific canary credentials, which provide another way to detect suspicious credential use and attribute it to an agent. We tested the canary containment logic in an emulated AWS environment.

Our frontend is a React and TypeScript dashboard that displays agent activity, security events, credential exposure, and containment results.

For notifications, we connected DynamoDB Streams, EventBridge Pipes, Amazon SQS, Lambda, and Amazon SES. This allows recorded security incidents to automatically generate alerts through Slack, Discord, Telegram, and Gmail.

Challenges we ran into

One of our biggest challenges was making revocation effective while agents were actively running. Simply disabling an agent wasn't enough. We needed to ensure that future tool calls would be rejected and that previously issued credentials could be handled appropriately.

Another challenge was credential detection. Sensitive information can appear in different formats, including encoded text or information spread across multiple requests. Building a detector that catches suspicious activity without blocking legitimate workflows required extensive testing.

We also had to think carefully about shared credentials. Automatically rotating every exposed key could interrupt unrelated agents or services, so we implemented ownership-aware rotation and a separate flagging process for shared credentials.

Finally, integrating work from six teammates was a major engineering challenge. We were building the Gateway, backend, credential-management system, detection layer, agent workflows, dashboard, and notifications in parallel. Keeping the interfaces consistent while integrating everything into a functioning AWS deployment took significant coordination.

Accomplishments that we're proud of

Our biggest accomplishment was building an integrated security platform that goes beyond detecting compromised AI agents.

We developed a working system that can revoke an agent's access, block subsequent protected requests, track credential exposure, and coordinate credential rotation without unnecessarily affecting other workers.

We also built a real-time dashboard that lets operators understand what's happening across their agent fleet and investigate security incidents.

Another major milestone was deploying our notification infrastructure to AWS and verifying that actual security events traveled through DynamoDB Streams, EventBridge, SQS, and Lambda to reach Slack, Discord, Telegram, and Gmail.

We tested notification delivery, containment summaries, retries, dead-letter queues, and security alarms using real AWS infrastructure.

We're especially proud of the layered architecture. Instead of depending on a single detection method, BURN combines identity, access enforcement, credential tracking, outbound monitoring, canaries, and containment.

What we learned

The biggest lesson we learned was that AI agent security is about more than preventing attacks. It's also about limiting the damage after something goes wrong.

We learned that revoking an identity and revoking the information an agent has accessed are two different problems.

We also learned how important credential ownership is. A security response that blindly rotates shared credentials can cause more disruption than necessary, so containment needs to be precise and evidence-based.

On the technical side, we gained experience integrating AWS security services, designing event-driven systems, working with agent authentication, and testing the limitations of detection systems.

Most importantly, we learned that building reliable AI infrastructure requires thinking about failure scenarios just as much as successful ones.

What's next for Burn: AI Agent Security

Our goal is to turn BURN from a hackathon project into a security platform that companies can use to manage AI agents at scale.

We want to expand support for more credential providers, cloud environments, and agent frameworks so BURN can protect agents regardless of where they're deployed.

We're also planning to improve credential-leak detection, expand automated canary-based incident response, and make agent onboarding easier for developers.

Another priority is improving recovery workflows so compromised workers can be safely replaced and their tasks resumed without exposing sensitive information.

Long term, we envision BURN becoming a security and containment layer for enterprise AI agent systems.

Because stopping a compromised agent shouldn't be the end of your security response. It should be the beginning of containment.