andreadev

4 माह पहलेdiscuss

[dead]

4 माह पहलेdiscuss

Not surprised by the 73%. Even people who never carry cash anymore can see the problem with going fully digital — you're one outage or one policy change away from not being able to buy groceries. Cash doesn't need wifi, doesn't need approval, doesn't go down for maintenance.

The 30% usage stat makes it even more interesting. These aren't cash diehards. These are people who tap their card for everything but still don't want the analog option killed off. You protect the thing you might need, not just the thing you use every day.

andreadev

4 माह पहलेdiscuss

You are wrong but I am not going to keep going back and forth.

andreadev

4 माह पहलेdiscuss

Which part specifically?

andreadev

4 माह पहलेdiscuss

The framing in this thread is full-duplex vs composable pipeline, but I think the real architecture is both running simultaneously — and this library is already halfway there.

The fact that qwen3-asr-swift bundles ASR, TTS, and PersonaPlex in one Swift package means you already have all the pieces. PersonaPlex handles the "mouth" — low-latency backchanneling, natural turn-taking, filler responses at RTF 0.87. Meanwhile a separate LLM with tool calling operates as the "brain", and when it returns a result you can fall back to the ASR+LLM+TTS path for the factual answer. taf2's fork (running a parallel LLM to infer when to call tools) already demonstrates this pattern. It's basically how humans work — we say "hmm, let me think about that" while our brain is actually retrieving the answer. We don't go silent for 2 seconds.

The hard unsolved part is the orchestration between the two. When does the brain override the mouth? How do you prevent PersonaPlex from confidently answering something the reasoning model hasn't verified? How do you handle the moment a tool result contradicts what the fast model already started saying?

andreadev

4 माह पहलेdiscuss

The bit about multiplication being ~12x faster than addition is worth pausing on. In silicon, addition is the "easy" operation — but here the complexity hierarchy completely inverts. Makes sense once you think about it: multiplication decomposes into parallel byte-pair lookups (which neural nets handle trivially as table approximation), while addition has a sequential carry chain you can't fully parallelize away.

Funny enough, analog computing had the same inversion — a Gilbert cell does multiplication cheaply, while addition needs more complex summing circuits. Completely different path to the same result.

What I haven't seen discussed: if the whole CPU is neural nets, the execution pipeline is differentiable end-to-end. You could backprop through program execution. Useless for booting Linux, but potentially interesting for program synthesis — learning instruction sequences via gradient descent instead of search. Feels like that's the more promising research direction here than trying to make it fast.

andreadev

4 माह पहलेdiscuss

I think everyone's focusing on the core count, but the packaging story is way more interesting here. This thing is 12 separate chiplets on 18A stacked on base dies made on Intel 3, connected to I/O tiles on Intel 7. Three different process nodes in one package, shipping at volume. That's nuts.

And it's clearly an IFS play too. Intel Foundry needs a proof point — you can publish PDKs all day, but nothing sells foundry credibility like eating your own cooking in a 288-core server part at 450W. If Foveros Direct works here, it's the best ad Intel could run for potential foundry customers.

The chiplet sizing is smart for another reason nobody's mentioned: yield. 18A is brand new, yields are probably rough. But 24 cores per die is small enough that even bad yields give you enough good chiplets. Basically AMD's Zen playbook but with a 3D twist.

Also — 64 CXL 2.0 lanes! Several comments here are complaining about DDR5 prices, which is fair. But CXL memory pooling across a rack could change that math completely. I wonder if Intel is betting the real value isn't the cores but being the best CXL hub in the datacenter.

The ARM competition is still the elephant in the room though. "Many efficient cores" is what ARM has always done natively, and 17% IPC uplift on Darkmont doesn't close that gap by itself.

andreadev

5 माह पहलेdiscuss

The strongest point here is one that rarely gets enough attention: the leap from "very smart" to "all-powerful" is completely unjustified. Even if you grant every assumption about alignment failures and emergent goals, you still need to explain how a neural network acquires physical resources, energy, supply chains, and weapons. Nobody ever does. It's just assumed that intelligence = omnipotence, which is basically theology.

Where I think the paper goes wrong is in treating the whole alignment problem as anthropomorphism. You don't need a machine to be "alive" or "want" things for misaligned optimization to be dangerous. A system relentlessly optimizing for a bad proxy metric can do real damage without any consciousness whatsoever — we already see this with recommendation algorithms. The paper waves this away by saying we caught the lab examples, but that's the whole point: we caught the easy ones.

The governance framing at the end is correct though and I wish it got more airtime. Regulating "AI" as one thing makes about as much sense as regulating "software" as one thing.

andreadev

5 माह पहलेdiscuss

Hi HN, I'm Andrea.

I run AI agents connected to databases, APIs, and filesystems. The problem: every agent gets full access to everything, with no enforcement layer between intent and execution.

SentinelGate is a firewall that sits between the agent and the system. Start the server, wrap any agent:

    sentinel-gate start                      # MCP proxy only
    sentinel-gate run -- python my_agent.py   # full protection

It auto-detects the runtime (Claude Code, Gemini CLI, Python, Node.js) and injects interceptors. Every action is evaluated against CEL policy rules before execution. Denied actions never happen.

Three layers: MCP proxy, HTTP gateway, runtime hooks — one port, one Go binary, one Admin UI with audit trail.

Honest about limitations: runtime hooks are best-effort — a hostile agent can bypass them via FFI or raw sockets. The HTTP gateway adds network-level enforcement. Together they give you defense in depth, not an OS-level sandbox.

AGPL-3.0. Commercial licenses available.

What's missing?

andreadev

5 माह पहलेdiscuss

Fair point, if it's a true point-to-point VPN between just the two boxes, there's not much "in between" to worry about. TLS on top is mostly defense in depth at that point. What I had in mind was the more common setup where your app and DB sit on a shared network (VPC, corporate LAN). The traffic between them is unencrypted, and you're trusting every piece of infrastructure in that path (switches, hypervisors, sidecar containers) to not be compromised.

andreadev

5 माह पहलेdiscuss

Encrypted in transit yes, but only between the VPN endpoints. Anything already inside the network (compromised host, rogue container, bad route) sees your queries in cleartext. TLS on the connection itself gives you end-to-end encryption between your app and Postgres, no matter what's going on in the network in between. Same reason people moved to HTTPS everywhere instead of just trusting the corporate firewall. And with connection pooling you pay the TLS handshake once and reuse it, so the overhead is basically nothing.

andreadev

5 माह पहलेdiscuss

Exactly, and that's one more reason I went with a userspace proxy — no kernel deps, runs anywhere, way easier to debug.

andreadev

5 माह पहलेdiscuss

True, but logging tells you what happened, a proxy lets you decide what's allowed to happen before it hits the database. Policy enforcement, tenant isolation, that kind of thing. They're complementary really.

andreadev

5 माह पहलेdiscuss

Yeah, more and more. Zero-trust is pushing TLS everywhere, even inside VPNs — lateral movement is a real thing. And several compliance frameworks now expect encryption in transit regardless of network topology. With connection pooling the overhead is basically zero anyway.

andreadev

5 माह पहलेdiscuss

The proxy vs packet capture debate is a bit of a non-debate in practice — the moment TLS is on (and it should always be on), packet capture sees nothing useful. eBPF is interesting for observability but it works at the network/syscall level — doing actual SQL-level inspection or blocking through eBPF would mean reassembling TCP streams and parsing the Postgres wire protocol in kernel space, which is not really practical.

I've been building a Postgres wire protocol proxy in Go and the latency concern is the thing people always bring up first, but it's the wrong thing to worry about. A proxy adds microseconds, your queries take milliseconds. Nobody will ever notice. The actual hard part — the thing that will eat weeks of your life — is implementing the wire protocol correctly. Everyone starts with simple query messages and thinks they're 80% done. Then you hit the extended query protocol (Parse/Bind/Execute), prepared statements, COPY, notifications, and you realize the simple path was maybe 20% of what Postgres actually does. Once you get through that though, monitoring becomes almost a side effect. You're already parsing every query, so you can filter them, enforce policies, do tenant-level isolation, rotate credentials — things that are fundamentally impossible with any passive approach.

andreadev

5 माह पहलेdiscuss

You're right, the GRANT layer is closed by default in PostgreSQL and PostgREST respects that. But in practice with Supabase, the very first thing you do is `GRANT ALL ON table TO authenticated` (and often `anon`) because nothing works through the client SDK without it. Every tutorial does this, every LLM-generated scaffold does this. At that point the first two layers are effectively gone and RLS is what's left. That's what I meant — not that PostgreSQL lacks defense in depth, but that Supabase's typical workflow collapses it down to one layer pretty quickly. Good to hear they're working on closed-by-default though. Kind of proves the point that the current model has been a problem in practice.

andreadev

5 माह पहलेdiscuss

The prompt injection thing is especially nasty for agents because they process untrusted input (web pages, emails, documents) and can take real actions. With a chatbot, prompt injection makes it say something dumb. With an agent that acts as you, a malicious payload hidden in an email could make it forward your contacts, reply on your behalf, whatever. You can't fix this in the model alone — you need an enforcement layer outside the model that limits what it can actually do regardless of what it thinks it should do. I'd bet Apple is working on exactly this and it's why they're taking their time.

andreadev

5 माह पहलेdiscuss

RLS on Postgres is fine — I use it in production for tenant isolation and it works great. The problem is that Supabase puts it as the only thing standing between the public internet and your data. PostgREST translates HTTP straight into SQL, so if you get a policy wrong (or forget one), game over. Behind a normal backend, a bad RLS policy is a defense-in-depth failure. In Supabase's model, it's a breach. That's a huge difference, and it gets worse when LLMs are writing the code because they'll happily scaffold a full app without ever thinking about access control.

andreadev

5 माह पहलेdiscuss

Hi HN,

MCP gives agents access to tools — databases, file systems, APIs. The problem is there's no access control layer. An agent with a database tool can run any query. An agent with file access can read anything. The only safeguard right now is a user clicking "Allow" on a prompt they probably won't read.

Sentinel Gate is a proxy that sits between your MCP client and servers. Every tool call gets checked against RBAC policies before it reaches the server.

The key design decision: *deterministic rules, not AI*. Policies are written in CEL (Common Expression Language). If a rule says deny, it denies. No LLM in the security path, no prompt injection possible against the firewall itself. You get a full audit log of every tool call — what was requested, what was allowed, what was blocked.

Built in Go. Self-hosted. PostgreSQL for audit logs, Redis for sessions. AGPL-3.0.

It's early — we're looking for feedback from teams running MCP in production or planning to. What's missing? What would make this useful for your setup?

Submissions

Max severity Flowise RCE vulnerability now exploited in attacks

Show HN: SentinelGate – Access control for AI agents (open-source MCP proxy)

[untitled]

Show HN: SentinelGate – Universal Firewall for AI Agents (Open Source, Go)

Show HN: Sentinel Gate – Open-source RBAC firewall for MCP agents

comments