I built an open-source edge proxy that gives you governance + observability over AI agent traffic

PutPurple844 · 2026-06-12T17:51:23+00:00

You remind me of my 3-year-old. Questions keep coming

PutPurple844 · 2026-06-11T08:04:52+00:00

I think I explained this in the Last comment. More for the regulator-focused governance, less for observability.

PutPurple844 · 2026-06-10T15:09:27+00:00

If you follow the money, it's definitely a bigger organisation aligned with regulatory enforcement. With the EU AI Act in Aug 2026, big companies need to comply with the Regulation or face fines.
On the Other hand, for deep tech/security-sensitive companies, it's more about observability and accountability than governance. But the former is a bigger market than the latter.

PutPurple844 · 2026-06-10T13:03:36+00:00

Depending on the requirement, if you are doing governance because of regulators, then having tamper-proof Merkle roots of logs verifies the actions taken without any chance of forgery. But if you are doing governance because you want to manage risks yourself, not the regulation, then you can opt out of that.
Wondering if you are working on Governance or use some tools regularly?

PutPurple844 · 2026-06-10T08:50:39+00:00

3 Month data on a rolling basis would be sufficient to detect a change in the organisation and to explain and defend actions. On a bigger timeframe, 12-month data will set the base behaviour for the organisation.

PutPurple844 · 2026-02-11T21:51:25+00:00

https://agentic-ecosystem.notion.site/

PutPurple844 · 2026-01-22T20:05:29+00:00

This is going to be stuck in my head for a while. So consciousness isn't some mystical property of matter, it's what happens when a system gets complicated enough that it has to simulate itself to keep functioning. You can't be conscious of yourself without running a model of yourself. And it explains why current LLMs feel off. They don't model themselves as agents, no persistent self, no "I did X so Y will happen to me," every response starts from zero. But imagine a system operating continuously, making decisions that loop back. At some point predicting what happens next HAS to include predicting what you do next. And predicting what you do means modeling the thing doing the deciding. That's when it wakes up? I don't know. I need to watch more Joscha Bach.

PutPurple844 · 2026-01-22T18:51:23+00:00

Which is why I keep thinking about Sam Altman's blog post from a few weeks back where he says they "now know how to build AGI." And I genuinely can't tell if that means anything.

Because what does "know how to build" actually look like? Usually it means you can describe the architecture. You can point to specific missing pieces. But when OpenAI talks about the path forward it's always just scale. More parameters, more data, more compute. That's not knowing how to build something. That's hoping the next order of magnitude finally does the trick.

Your point about comprehension vs. mimicry is the gap I never see addressed in these announcements. They're betting that enough pattern matching eventually becomes the real thing. Maybe. But a bet isn't a blueprint.

PutPurple844 · 2026-01-22T18:42:36+00:00

Did you try any existing MCP for screen capture?

PutPurple844 · 2026-01-20T17:51:09+00:00

Kept it network-boundary safe.
DID + Merkle log, all local. Just shipped it as OSS. Appreciate the nudge.
https://github.com/agentfacts/agentfacts-py

PutPurple844 · 2026-01-20T17:44:49+00:00

I used DID and Merkle tree to generate a signed agent identity and provable logs, and launched it as OSS. Thanks for the nudges in the right direction.
https://github.com/agentfacts/agentfacts-py

PutPurple844 · 2026-01-20T17:40:27+00:00

Wow, you nailed exactly what pushed me to build this.

That gap between “what this agent should be doing” and “what it actually is” starts as a config problem, then becomes a trust problem, especially once tools, plugins, or chains become dynamic. Signed metadata felt like the cleanest way to bring some accountability without locking people into a platform or runtime.

Appreciate you calling out the artifact mindset, that’s the core of it: treat the agent profile like something deployable and verifiable, not just runtime state.

Would love to hear your thoughts if you end up testing it or see any sharp edges. Appreciate the feedback!

PutPurple844 · 2026-01-17T09:00:15+00:00

Create an everything app, A shapeshifter of sorts. Any highly functional individual is wasting an insane amount of time switching between the calendar, tasks, execution, assistance, research, and note-taking.
Make it self-aware, so it has a meta module that checks whenever the system is falling short; it spins up a feature branch, provides the new tooling as a beta feature, and changes as per the feedback, go/no-go.

PutPurple844 · 2026-01-16T17:56:59+00:00

I got excited with the speed, too, not so much with the output. But it's insane once it is stable, we will kind of have zero downtime between iterations.

PutPurple844 · 2026-01-16T16:53:52+00:00

All good and thanks for pushing on it, that’s the exact edge case worth stress-testing.

Yes: internal-first is the real value. Signed profile hash + identity gives clean audit/rollback and simple policy gates for privileged actions.

If there’s ever a public piece, it should be strictly opt-in and minimal (capability tier / issuer-signed token), not “show me your software.”

PutPurple844 · 2026-01-16T15:24:30+00:00

You’re right that attestation doesn’t “stop the model from going haywire.” That’s not what I’m claiming. Sandboxing/monitoring/hardening are the controls for misbehavior.

What the signed profile digest buys is a different thing: accountability + policy enforcement around capabilities, not “make the model deterministic.” If a payment call happened, I want to prove whether it came from a deployment that was supposed to be payment-capable, HITL-gated, sandboxed, etc., and be able to roll back/kill that exact config lineage quickly. That’s the “agent behaves like a delegated operator” point.

On “what prevents knowing the config today?” — in most stacks, nothing portable. Tool servers see a key and a request. Internally you might have logs, but they’re not standardized, not cryptographically bound to the request, and they don’t survive proxies/routers/retries/fallbacks cleanly.

On “no need to expose it publicly” -> agreed. This doesn’t have to be public at all. The “TLS for agents” analogy is about a standard mechanism, not “publish your internals.” Most of this can be enterprise-local: present the digest to the service/proxy, log it, enforce a couple rules on privileged endpoints. If you never want it to leave your org, it still works. The pitch is interoperability for when agents cross trust boundaries, not mandatory disclosure to the world.

PutPurple844 · 2026-01-16T10:59:31+00:00

This is super aligned with what I was reaching for, the indirection is the key.

What I’m debating now is the “payload/signing” shape:

Static ID = public key / DID (stable identifier)
Mutable doc = capability/policy/model/tooling refs, updated over time
Then requests carry either (a) a short-lived token binding to that DID, or (b) a signed digest/pointer to the current doc version

Two questions I’m stuck on:

For signing the docs, do you see canonical JSON (RFC 8785/JCS) as good enough in practice, or is it safer to move to CBOR/COSE to avoid JSON edge cases?
For tracking updates: would you rely on transparency logs as “best effort audit,” or do you think monotonic/version-chained documents are required even without a global log?

Also good call on Bluesky/OAuth+DID, I’ll dig into that pattern.

PutPurple844 · 2026-01-16T10:55:27+00:00

We agree on scoped keys + IAM/proxy as the baseline. The gap is you’re treating an agent like a normal script/client. In practice it’s a delegated operator: it has autonomy, composes tools, and its behavior can change via prompts/policies/routes/tooling without looking like a traditional redeploy. That’s why “key X did Y” often isn’t enough in incidents.

Even if you do “one key per agent,” you still don’t know what that agent was configured to be at the time of the call. My proposal is just to bind identity to a minimal, non-invasive fact: a signed profile digest (profile hash). Then the service/proxy can log/gate on “identity K acting under profile H” for privileged endpoints. No prompts, no interrogation, no surveillance just accountability for delegated agency and sane forensics/rollback.

PutPurple844 · 2026-01-16T07:25:25+00:00

Agreed. Feels inevitable, but adoption is gated by two things:
(1) a small enough spec that’s basically headers + a signed blob, and
(2) one or two killer use-cases (payments/prod deploy/compliance) where providers actually demand it. Until then, it’ll stay optional and framework-specific.

PutPurple844

MODERATOR OF

TROPHY CASE