Built a compliance layer for AI agents — logs every tool call, masks PII, holds risky actions for approval

High-consequence approval rule, every time.
Audit replay is important but passive, people nod and move on. PII masking is expected, they assume you do it. But when you show an agent mid flight, about to do something it shouldn't, and it stops and routes to a human for signoff that's the moment it clicks. You can see it on people's faces.
The rule we use in demos: flag any external API call that includes a dollar amount over $5,000. Fire the tool call, watch it intercept in real time, approval request lands in the dashboard. Ten seconds. No explanation needed after that.

Honestly all three, but in different buyer profiles. The "prove what happened" question comes up most with compliance and security teams, they need to show an auditor exactly what the agent did and why it was permitted. PII is close behind, especially in healthcare and legal where a single exposure is a reportable incident. Risky tool calls are more of a developer concern, they are the ones who have already had an agent delete something it shouldn't have.

On the approval noise problem: the key is that rules are specific, not broad. "Block any write to the production database" has very few edge cases. "Block anything risky" flags everything and trains people to click through. The customers who get the most value out of approvals are the ones who write rules that fire rarely but matter when they do.

All three of those are real and I won't pretend they are fully solved.
False positives: because the rules are customer written in plain English or from uploaded document, they tend to be specific from the start. "Don't send emails to anyone outside the company domain" doesn't leave much room for ambiguity. The failure mode is when someone writes a vague rule and then wonders why everything is getting flagged.

Rule sprawl: this is going to get worse over time and I don't have a clean answer yet. Conflict detection between rules is something we will need to build and in the roadmap.

Latency: typically 80–150ms per call. Not zero, but if the agent is already hitting a database or an external API, we are not the bottleneck.

On shadow AI being underrated, that's where most organisations have zero visibility right now. An agent with a proper API integration is at least visible. An employee pasting customer data into ChatGPT is not.

The threshold is customer defined, which is what keeps it signal rather than noise. They write rules like "flag any file deletion," "flag payments over £500," "flag emails to external addresses." We don't assign a universal risk score, we apply their rules.

The click through failure you are describing usually means the rule is too broad. When someone approves the same thing 40 times in a row, that is the system telling you that action should be on an allow list, not going through approval. We let customers do that, approve once and create an exception. The approval queue should feel meaningful when it fires, not like a formality.

Your framing about privacy guarantees costing something architecturally is right. A policy line that says "we don't store PII" is worth nothing. PII masking that runs before the log entry is written is worth something.

The blockchain critique is fair and i have heard it more than once. What Polygon gives us that a self hosted hash chain doesn't is external verifiability, anyone can query the contract without trusting that we have not modified our own logs. A hash chain we control can be swapped before an audit. An on chain hash can't. Whether that's worth the dependency is a legitimate question and I would rather have that conversation with a customer who cares about it than lead with it as a headline.

On the shadow AI point, you are right and it's the thing I think about most. The browser extension logs are the most sensitive data in the system. We apply PII masking before storage and enforce the same tenant scoped access and retention limits as the API layer. But the works council angle in particular is something I haven't communicated clearly enough to EU prospects. That's a gap to be closed and will be fairly soon.

This is the most useful framing I have seen in this thread. You are right, the category doesn't create urgency. What creates urgency is a CTO who can't get legal sign off on a production agent because they can't explain what it will and won't do. Or a security review that stalled because there's no audit trail. That is when this becomes a real problem to solve, not a nice to have.

The customers who have actually integrated are almost always ones where a specific blocker already existed, not ones shopping for governance in the abstract. I should probably be leading with "what would stop you from putting this agent in production tomorrow" rather than feature lists. That question gets to the real wedge faster.

That's the right way to put it. Most tools give you a dashboard of what already went wrong. We sit in the call path before the action executes. That is a different product even if the UI looks similar.

The approval fatigue question is the honest challenge. What we have seen is that it comes down entirely to rule precision. Broad rules create constant noise and people stop reading the requests. Precise rules fire rarely, which means when something does land in the approval queue, it actually gets attention. If a team is reviewing 50 approvals a day, something is wrong with how their rules are written, not with the approval mechanism itself. The goal is that an approval is unusual enough to be meaningful.