We gave agents tools — but who gets to say "no"?

Over the last year or two, the agent ecosystem has grown incredibly fast: LLM-based agents that touch the file system, run terminal commands, call APIs, write to databases, and even update their own memory are now commonplace. Thanks to MCP (Model Context Protocol), connecting an agent to a new tool takes minutes.

But there's something easy to miss here: the fact that an agent can connect to a tool doesn't mean every request it makes to that tool is safe, authorized, and compliant with corporate policy.

A file-deletion command equivalent to rm -rf, a write request to a production database, privilege escalation, sensitive data exfiltration, or an agent writing false information into its own memory as if it were "true" — these are all hard-to-reverse operations, and in most systems today they're either not audited at all, or only logged after the fact.

HUQAN is being built as a local-first, deterministic trust layer that steps in before the action happens, not after.

Let's start with what HUQAN doesn't do

This isn't an observability product that says "we're watching the agents," nor an anomaly-detection tool. It's not a dashboard that reports on agent behavior after the fact either. And most importantly:

The final decision authority does not rely on another LLM's free-text interpretation.

That last point matters, because a lot of today's "AI security" solutions essentially have one model police another model — which is a bit like asking someone who can pick locks to double-check the lock. The same class of vulnerabilities (prompt injection, social engineering, context manipulation) can affect both sides.

Architecture: typed action → deterministic decision → evidence

HUQAN's core decision pipeline works like this:

  1. Input is normalized — agent identity, task context, requested action, authorization scope, data provenance, and the active policy version are converted into a canonical structure.

  2. The deterministic engine decides — instead of free-text interpretation, rules operating on a typed action + schema + verifiable system state produce one of four outcomes:

    • ALLOW — the action is executed
    • REVIEW — sent for human approval
    • BLOCK — the action is stopped
    • DRY_RUN_ONLY — can only be run in a sandbox/dry-run environment

  3. A Trust Receipt is generated — the decision's inputs, the applied policy version, the reasoning, and the outcome are stored as a signed, hash-linked, auditable, append-only record.

The end-to-end chain looks roughly like:

resolver → adapter → verification core → writer/reader → signing chain

The structural, fail-closed parts of this chain (i.e., defaulting to deny when policy or identity is invalid) are already working and under test; the signing and content-integrity binding layers will be completed in separate, auditable stages. In other words, there's no claim here that "everything is done, production-ready" — this is a gradual, evidence-based hardening process.

A concrete example: in prototype testing, a request attempting to delete a production database was stopped instantly with a BLOCK decision, while a scenario requiring outside review was flagged as REVIEW and routed to a human for approval.

Memory lives inside the same trust boundary too

Most "agent security" conversations stay at the action/tool-call layer. HUQAN takes a different view: information an agent writes into its persistent memory can be just as dangerous as an action.

The Trusted Memory component evaluates every piece of information headed into memory against criteria such as:

  • Source — where did this information come from?
  • Contradiction — is it consistent with existing knowledge?
  • Authorization — who or what is allowed to write this?
  • Approval conditions

The outcome is again an accept / reject / review decision, receipted along with data provenance. The goal isn't personalization — it's holding memory writes to the same deterministic decision-plus-evidence discipline as actions.

Why does "local-first" matter?

Corporate policy and sensitive context don't need to be sent to a third-party cloud for evaluation. On-premise deployment, private cloud, or isolated environments are all meant to be supported. For teams using privileged file/terminal/API/database tools, and for organizations with strict data-sovereignty requirements, this solves the dilemma of "I want an audit trail, but I don't want my data leaving the building."

Competition: what it doesn't copy, what it combines

Products like Check Point AI Guardrails / Lakera Guard, CyberArk Secure AI Agents (now part of Palo Alto Networks), Prisma AIRS 3.0, and Zenity already offer strong runtime policy, identity, and behavioral-analysis capabilities. HUQAN isn't trying to copy the scope of these platforms.

Its focus is narrower and built for integration:

deterministic action judgment + human approval + evidence receipt

— combined with memory admission inside the same local trust boundary. That's why the first commercial product is named HUQAN Agent Action Firewall, with the MCP Trust Gateway module as the initial entry point; since the core is protocol-agnostic, it's meant to expand via REST API, CLI, IDE plugins, and custom adapters.

Verification discipline: "not done until proven"

The project takes a fairly strict stance on tying claims to test results. Example success criteria include:

  • 100/100 identical decisions across 100 runs for the same normalized input/policy/system state
  • 100% fail-closed behavior on invalid identity or corrupted policy
  • A complete, verifiable Trust Receipt for every accepted decision
  • Adversarial testing (prompt injection, data exfiltration, malicious tool calls) using scenarios adapted from agent-attack benchmarks like AgentDojo and InjecAgent — measuring attack success rate with the gate on vs. off

An independent security review will also be brought in separately — so this isn't a case of "tested itself, passed itself."

What's in it for developers?

As a non-commercial, complementary output, a lightweight open-core / Developer Edition along with an MCP/IDE plugin is planned. This edition isn't a revenue product — it's meant to produce technical evidence and engage with the ecosystem.

Closing

HUQAN doesn't claim to be a "finished product" yet — the team says so openly. But the framework it lays out points to a gap that's becoming increasingly hard to ignore in the agent ecosystem: as tool access grows, the combination of pre-action decision, human approval, and auditable evidence is no longer a "nice to have" — it's a baseline requirement.

The idea of unifying action safety and memory admission under the same local, deterministic trust boundary is a direction worth watching, especially for teams working with privileged tools and organizations that care about data sovereignty.

This post is based on technical documentation from HUQAN's development process. The project is under active development; any claims of performance or superiority hold only to the extent they're proven through testing, adversarial scenarios, and pilot validation.