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

This makes a lot of sense — most people are focused on “can the agent do X” and not “what happens when it does the wrong X.”

Biggest concern for me would be less about logging and more about real-time intervention. Audit trails are great after the fact, but the scary failures are the ones that execute before anyone notices. So the value is really in how strict and reliable that pre-execution check layer is.

Also curious how you handle:

• false positives (blocking too much kills usability fast)
• rule complexity over time (governance tends to sprawl)
• latency impact if you’re sitting in the middle of every call

The shadow AI browser extension angle is actually underrated — that’s probably where a lot of real risk is right now.

Overall feels like you’re targeting the right gap. The hard part is going to be balancing control vs not slowing teams down.

This resonates — I build on-device processing into a mobile app for the same privacy reason (sensitive user text never leaves the device), and the recurring lesson is that a privacy guarantee is only convincing when it costs you something architecturally, not when it's just a policy line.
"Holds risky actions for approval" is the interesting part: how do you set the risk threshold so the approval step doesn't become noise people just click through?
That balance feels like where this kind of product lives or dies.

you asked for the biggest concern — the shadow-AI browser extension is it. the moment you log everything employees type into ChatGPT/Claude, that store becomes a bigger PII honeypot (and in the EU a works-council + GDPR problem) than the agents you're governing. it needs the strictest retention and access controls of anything in the system. also, gently: "anchored to blockchain" reads as marketing — a hash-chained append-only log, where each entry signs the previous hash, gives you the same tamper-evidence without the dependency. what does the chain buy you that a signed hash chain doesn't? solid space though, this is becoming table stakes fast.

AI governance is the right category, but early users usually won’t adopt a control layer just because the category is important.They usually care when one specific risk is already blocking deployment, procurement, customer security review, or internal approval.So the sharper question may be:What risk would make you uncomfortable putting an agent into production?The signal I’d look for is not whether people say PII masking, audit logs, approvals, or kill switches sound useful.
It’s whether a team can point to a real workflow where:

• an agent is already making tool calls in production or an internal workflow
• deployment was paused because of compliance, security, customer review, or governance concerns
• there was a recent action that felt too risky to let the agent run automatically
• they would be willing to connect one concrete agent workflow to TrustLoop as a test

That would probably tell you which governance feature matters first.Without that, “AI governance” may be correct but still too broad. The first wedge is likely the specific risk that stops a real team from shipping agents safely.

What stood out to me is that you're not treating compliance as logging after the fact—you’re treating it as a control layer before execution. That shift matters. Most “AI governance” tools are forensic. This is closer to runtime decision gating. The real test will be how often teams actually allow humans to intervene vs defaulting back to automation when things get noisy.