My question: in a real production environment, what’s your enforcement point that the agent cannot bypass? Like, what actually guarantees the tool call isn’t executed unless it passes policy?

Some specific things I’m curious about:

Are you enforcing permissions inside each tool wrapper, at a gateway/proxy, or via centralized policy service?

How do you handle identity + authorization when agents act on behalf of users?

Do you log decisions separately from execution logs (so you can answer “why was this allowed?” later)?

How do you roll out enforcement safely (audit-only/shadow mode -> enforcement)?

What failure modes hurt most like policy bugs, agent hallucinations, prompt injection, or tool misuse?

Would love to hear how people are doing this in practice (platform/security/infra teams especially)

Comments URL: https://news.ycombinator.com/item?id=46740645

Points: 3

# Comments: 2

I actually published a 40-page paper (DOI: 10.5281/zenodo.18296731) that defines this exact 'Action Authorization Boundary.' It treats the LLM as an untrusted actor and enforces determinism at the execution gate.

Faramesh Core is the reference implementation of that paper. I’d love for you to check out the 'Execution Gate Flow' section. it would be a massive win to see a Faramesh-Cordum bridge that brings this level of semantic security to your orchestrator.

Code: https://github.com/faramesh/faramesh-core

My focus with Faramesh.dev is slightly upstream from the scheduler. I’m obsessed with the Canonicalization problem. Most schedulers take a JSON payload and check a policy, but LLMs often produce semantic tool calls that are messy or obfuscated.

I’m building CAR (Canonical Action Representation) to ensure that no matter how the LLM phrases the intent, the hash is identical. Are you guys handling the normalization of LLM outputs inside the Safety Kernel, or do you expect the agent to send perfectly formatted JSON every time?

I'm looking into building a hard "Action Authorization Boundary" (AAB) that sits outside the agent's context window entirely. The idea is to intecept the tool-call, normalize it into intent against a deterministic YAML policy before execution.

A few questions for those building in this space:

Canonicalization: How do you handle the messiness of LLM tool outputs? If the representation isn't perfectly canonical, the policy bypasses seem trivial.

Stateful Intent: How do you handle sequences that are individually safe but collectively risky? For example, an agent reading a sensitive DB (safe) and then making a POST request to an external API (dangerous exfiltration).

Latency: Does moving the "gate" outside the model-loop add too much overhead for real-time agentic workflows?

I’ve been working on a CAR (Canonical Action Representation) spec to solve this, but I’m curious if I'm overthinking it or if there’s an existing firewall for agents standard I'm missing.

Comments URL: https://news.ycombinator.com/item?id=46733315

Points: 2

# Comments: 6

I built Faramesh because I wanted a hard, cryptographic boundary between the agent's "brain" and my actual infrastructure. It intercepts tool-calls and forces them through a deterministic gate before any code runs. If the action isn't in your policy, it simply doesn't exist.

The biggest headache was canonicalization.py. LLMs are messy—one model sends a float as 1.0, another as 1.00, and it breaks the cryptographic hash every time. I wrote a normalization engine to ensure that identical intent produces the exact same byte-stream and hash.

It’s open source (Python/Node SDKs). I’m curious if people think this should live at the framework level or as a standalone proxy. Tear the code apart:

https://github.com/faramesh/faramesh-core

For theory lovers, I'd invite you to read a paper i published just recently titled "Faramesh: A Protocol-Agnostic Execution Control Plane for Autonomous Agent systems" (Link below)

https://doi.org/10.5281/zenodo.18296731

Comments URL: https://news.ycombinator.com/item?id=46714023

Points: 1

# Comments: 0

We believe Faramesh is the first project to treat the 'Agent-to-System' bridge as a distributed systems problem rather than a prompting problem.

The hardest part to get right was the Deterministic Canonicalization. LLMs are inherently messy—one model might send {"power": 100.0} while another sends {"power": 100} for the same tool call. To build a reliable Action Authorization Boundary (AAB), we had to ensure that the semantic intent produces a stable, cryptographic hash every single time. Without this, you cannot have reliable RBAC, audit trails, or 'fail-closed' security for autonomous agents.

We’ve open-sourced the core logic today and would love for the community to tear apart our approach in canonicalization.py. We’re specifically interested in whether people think this architecture could eventually be standardized into a formal 'Agentic Firewall' protocol.

We built Faramesh to bridge this gap. It is the first formalized Action Authorization Boundary (AAB) for the agentic web—an open-source, protocol-agnostic execution gate designed to sit between an agent’s reasoning engine and the target system.

In 2025, everyone focused on the "Brain" (the model). In 2026, the bottleneck is the "Nervous System" (execution control). The industry is shifting from Model-mania to Infrastructure-mania; we believe agents shouldn't be "trusted"—they should be governed.

How it works: Unlike existing guardrail libraries that use more LLMs to "check" the first LLM (adding more stochasticity), Faramesh introduces a hard, cryptographic gate. It intercepts agent intent, canonicalizes it into a deterministic byte-stream, and validates it against a strict, logic-based policy engine before any code is executed.

Key Technical Details:

- Deterministic Canonicalization: We found that slight variations in JSON or float representation break audit trails. Faramesh handles lexicographical sorting and float normalization (e.g., ensuring 1.0 and 1.00 produce identical bytes) so that identical intent produces identical hashes.

- The AAB Protocol: This defines what an agent is allowed to do across any medium. Whether targeting REST APIs, gRPC, or raw Shell, the control logic remains the same.

- Zero Trust Execution: The agent never touches the target system directly. It sends a "Proposed Action" to the gate. If the engine is confused or a policy is missing, it fails closed and the action is blocked.

- Cryptographic Hashing: Every authorized action is hashed, creating an immutable, replay-protected audit trail of agent intent.

- SDK-First Integration: We’ve released SDKs for Python and Node.js to make this a drop-in layer for existing LangChain/AutoGen stacks.

We’ve open-sourced the core engine and the SDKs. We’re particularly interested in feedback on our canonicalization logic and the policy engine’s performance overhead.

Paper: https://zenodo.org/records/18296731 GitHub: https://github.com/faramesh/faramesh-core PyPI: pip install faramesh NPM: npm install @faramesh/sdk

Comments URL: https://news.ycombinator.com/item?id=46712202

Points: 1

# Comments: 2