Risk-Aware Agent Governance & Audit Trail

One-page document of Architecture

Inspiration

As AI agents become capable of taking real actions, we realized that simply giving an agent access to tools isn't enough. We need to know what an agent tried to do, whether it was authorized, and how risky that action was.

We wanted to explore what an accountability layer for AI agents could look like: a system where sensitive resources sit behind an enforcement boundary and every decision leaves an auditable trail.

What We Built

We extended our agent platform with a protected-resource relay, capability-based authorization, and risk-aware audit trail.

Agent requests to protected resources are routed through the relay, where the system verifies the agent's credentials and required capabilities before allowing the request to proceed. Unauthorized requests are blocked rather than reaching the underlying resource.

Every decision is recorded with information about the requested capability, resource, authorization result, and risk assessment. This lets us distinguish between normal agent behavior and suspicious or unauthorized activity.

Our demo shows both sides of the system:

An authorized request for a development resource succeeds. An unauthorized attempt to access a production resource is denied and recorded as a risk-bearing event. Repeated denied requests provide additional context for assessing suspicious behavior.

How We Built It

We implemented the governance layer around the existing agent runtime rather than relying on the model to enforce its own permissions.

The relay acts as the enforcement point:

Agent Request → Credential Validation → Capability Check → Resource Access

The result of each decision is then written to the audit trail, alongside a risk assessment based on the operation and its context.

This architecture means that even if an agent wants to access something it shouldn't, the protected resource remains behind a separate authorization boundary.

What We Learned

The biggest lesson was that prompt-level instructions are not security controls. Telling an agent not to access a resource is fundamentally different from enforcing that restriction at the resource boundary.

We also learned that audit logs become much more useful when they capture decisions and context, rather than simply recording that an API request happened. A denied request, the capability it required, and the reason it was denied provide much more actionable information.

Challenges

One challenge was making the demo reliably exercise the protected-resource path. An agent can sometimes answer a request from its existing context without actually making an external call, which means a natural-language prompt alone isn't sufficient to demonstrate enforcement.

We addressed this by making the protected resource and relay explicit parts of the architecture, allowing us to demonstrate a complete allow and deny flow through the same enforcement boundary.

Another challenge was balancing useful auditing with data protection. The system needs enough information to understand what happened without unnecessarily exposing the sensitive resource itself. This led us to make the audit trail about actions, authorization, and risk, rather than storing sensitive resource contents.

Ultimately, the project reinforced our belief that trustworthy AI agents need more than intelligence—they need boundaries, visibility, and accountability.