Automation is scaling faster than auditability.
That is the core problem I keep coming back to.
Modern systems do not just execute code anymore. They route decisions, move records, call tools, fan out across internal services, and increasingly do it through software that looks more like an agent than a script. The speed is new. The autonomy is new. The failure mode is also new: activity without witnesses.
For a long time, we treated logs as enough. If something mattered, the application would log it. If a boundary mattered, we would put a proxy in front of it. If a workflow mattered, we would trust the service owner to tell the truth about what happened.
That model is breaking down.
It is breaking down because governance is moving closer to the data plane. It is breaking down because regulation is no longer satisfied with hand-wavy intent. And it is breaking down because once you start letting AI systems touch real workflows, after-the-fact narration is not good enough.
DPDP sharpened that for me. AI audit made it impossible to ignore.
I do not mean "AI audit" as a slide-deck phrase. I mean the operational question that shows up the moment autonomous systems move from demo to actual work: what exactly did the system access, where did the data go, what protocol carried it, and what evidence exists if you need to explain it later?
That is the reason Panopticon exists.
The repo is here: github.com/harshit2283/panopticon.
What Panopticon does
Panopticon is an experimental eBPF-based observability and privacy engine for Linux hosts. At a high level, it watches traffic at the kernel boundary, captures selected plaintext from both cleartext and some TLS paths, reconstructs application-layer activity, detects likely PII, builds a service graph, and exports structured evidence through JSONL, Prometheus, and OTLP.
If you want one simple technical mental model: the kernel side emits compact events through a ring buffer, and user space runs small protocol state machines to turn those fragments into readable requests, responses, and flows. I will be following up with in-depth articles later, once I understand it inside out.
The important point is not any single parser or exporter. The important point is where the observation happens.
Panopticon sits behind the packet, at the point where application intent turns into actual movement across systems.
That distinction matters.
Logs are authored narratives. They tell you what the application decided to say. Proxies only see what you route through them. Dashboards are downstream of both. Packet-path observability changes the control point. It lets you ask what the system actually did on the wire, not what one component claimed it did after the fact.
Before autonomy, establish gates. Before delegation, establish evidence.
That is the real thesis here.
Why behind the packet matters
Most control systems are built too late in the chain.
They live inside application code, inside gateway policy, or inside manual review. That worked when software changed slower, ownership was clearer, and the asymmetry lived in who had access to a dashboard or a script.
Now the asymmetry is shifting.
Value is moving away from simple access and toward the ability to create, coordinate, and act across many systems quickly. AI agents accelerate that shift. They collapse the distance between intent and execution. They also make it easier to create sprawling chains of data movement that nobody can explain cleanly once the moment has passed.
If you care about trust, privacy, internal controls, or auditability, that is a bad place to be.
You need visibility at the layer where data leaves one boundary and enters another. You need to see protocols, destinations, and sensitive payloads while the system is acting, not only after someone has summarized the event in a log line or a ticket.
That is what I mean by observability behind the packet.
Why Panopticon
The literal meaning of panopticon is total visibility from a central vantage point.
That word comes with baggage, and it should. The surveillance interpretation is real. The prison metaphor is real. I do not think the answer is to pretend that away.
I think the more useful move is to invert it.
The point here is not universal observation as ideology. The point is enforceable visibility over systems that would otherwise act without witnesses. In the age of autonomous software, visibility is not only about control over people. It is also about accountability for machines.
If an agent can access tools, call internal services, touch customer data, and trigger downstream actions, then someone needs a vantage point from which that behavior can be observed, reasoned about, and bounded.
That is the role I want Panopticon to play.
DPDP, AI audit, and monitoring gates
DPDP raises the cost of ambiguity. Not just legally, but operationally.
Once privacy obligations become concrete, "we think the service behaves like this" is not a satisfying answer. Neither is "the logs looked fine." You need evidence that data movement is visible, attributable, and reviewable.
The same is true for AI audit.
If an AI system is going to retrieve records, traverse internal systems, or act with even modest operational freedom, then monitoring cannot be the cleanup layer. It has to be the gate. You put the gate in place first. Then you decide how much autonomy to allow.
That is not anti-agent. It is the opposite. If we want agents to do useful work in real environments, we need monitoring systems that are grounded in reality, not in optimistic application narratives.
The institution has to be able to answer basic questions under pressure:
- what moved
- where it moved
- what protocol carried it
- whether sensitive data was involved
- which system crossed the boundary
Without that, autonomy is mostly theater.
What this repo is, and what it is not
Panopticon today is an honest experimental MVP.
It is Linux-focused. It is not production-ready. IPv6 capture is not implemented. Kubernetes-aware identity resolution is not implemented. TLS coverage is partial. Go TLS is write-path only. Some protocol parsers are much more validated than others. The Helm chart exists, but production hardening is not the current claim.
I think that explicitness matters.
Too many systems try to borrow credibility by hiding their edges. I would rather make the boundary visible. The work becomes easier to trust when the limits are stated plainly.
The real question
The real question is not whether agents will go wild.
They will act wherever incentives, tooling, and delegated authority make it easy for them to act. The real question is whether our institutions can still see, explain, and bound what those systems are allowed to do once they are in motion.
That is the bet behind Panopticon.
Not that visibility solves everything. Not that packet-path observation is the only control that matters. But that without a monitoring gate at this layer, we will keep giving autonomy to systems we cannot actually audit.
And that is a bad trade.