DEV Community: Er.piyush Singh

🇮🇳 Building OmniCore OS: From an Idea to a Working Development Build:

Er.piyush Singh — Sun, 06 Sep 2026 06:44:57 +0000

🇮🇳 Building OmniCore OS: From an Idea to a Working Development Build

A few days ago, I shared the vision behind OmniCore OS.

Today, I want to share the next step in that journey.

The idea is no longer just a concept.

OmniCore OS is now booting as a working development build.

Getting an operating system to boot is only one milestone. The bigger challenge is building a platform where security, integrity, verification, and resilience are considered from the foundation up.

Why OmniCore OS?

Modern computing infrastructure depends on software that organizations need to trust, verify, and control.

Security should not simply be something added after a system has been built.

It should influence the architecture, build process, system configuration, update mechanism, and operational model from the beginning.

That is the direction we're exploring with OmniCore OS.

🛡️ Current Development Build

The current development stage includes:

Custom boot environment
Custom system identity and branding
Desktop environment
Installation environment
Security-focused system architecture
Build and deployment pipeline
System testing and validation
Foundation for future security and forensic capabilities

But the real challenge isn't simply making an OS boot.

The real challenge is building a system that can be trusted.

🔐 The Questions That Matter

Can the system be verified?

Can changes to critical components be detected?

Can updates be securely delivered?

Can the software supply chain be monitored?

What happens if the system is compromised?

Can useful forensic evidence be preserved?

These are the questions driving the engineering process.

BUILD → HARDEN → TEST → BREAK → FIX → VALIDATE

The objective is not to claim that the current build is already secure.

It isn't.

This is an early development build, and many components still need to be implemented, tested, and independently evaluated.

The goal is to continuously identify weaknesses and improve the architecture.

🚀 What Comes Next?

We are currently evaluating the next capabilities to implement, including:

System hardening
Integrity verification
Secure update mechanisms
Software supply-chain security
Security monitoring
Digital-forensics readiness
Offline and isolated deployment
Reproducible and auditable builds
Security-focused system tooling

The architecture will continue to evolve as development and testing progress.

🇮🇳 Building Toward Sovereign Computing

For me, sovereign computing means more than putting an Indian name on a product.

It means developing the capability to understand, control, secure, and continuously improve the technology stack.

Architecture.

Build systems.

Software supply chain.

Security controls.

Verification.

Deployment.

That is the broader direction behind OmniCore OS.

This Is Only the Beginning

The current ISO is a development build, not a final product or production release.

There is still a significant amount of engineering, testing, and validation ahead.

But seeing an idea move through:

Idea → Architecture → Build → Boot → Test → Improve

is an important milestone.

And now the real work begins.

🇮🇳 OMNICORE OS

Secure. Sovereign. Advanced.

Built by RAKSHANEX TECHNOLOGIES

Build the foundation.

Harden the system.

Break it.

Fix it.

Verify it.

I'd genuinely like to hear from developers, security researchers, OS engineers, DFIR professionals, and systems engineers:

What capabilities would you consider essential for a security-focused operating system at the foundation level?

When Your AI Agent Gets Breached, Can You Prove What It Did?

Er.piyush Singh — Tue, 01 Sep 2026 20:36:58 +0000

Introducing AgentTrace — an open-source, offline forensic tool for reconstructing AI-agent security incidents.

AI agents are no longer demos. LLMs wired to tools, memory, retrieval, and other agents are running in production — reading data, calling APIs, moving money, touching customer records. And like everything else that touches production, they get caught up in security incidents.

But investigating an AI-agent incident is not like traditional digital forensics. I kept running into the same wall, so I built a tool for it.

Why AI-agent forensics is genuinely different

Three things break the usual DFIR playbook.

1. The attack vector is natural language. When an attacker plants a malicious instruction in a document an agent will retrieve, that instruction looks identical to a legitimate query in every log most teams collect. There is no binary payload, no CVE signature, no network packet that lights up. The exploit is a sentence.

2. The anomaly is the sequence, not any single event. Every individual tool call the agent makes is authorized and looks normal. "Read a file." "Call an API." "Make an HTTP request." Nothing is wrong on its own. The attack is the order — retrieve poisoned content, then access a secret, then send data out. You cannot see it unless you have the whole chain.

3. The evidence is scattered and short-lived. The pieces live in six or seven different systems: LLM invocation logs, tool execution traces, MCP server logs, vector-store retrieval logs, OAuth records, egress logs. Different teams own each one. Different retention windows delete each one. One documented 2026 incident produced roughly 17,600 agent actions in five days; the team's own postmortem called reconstructing it by hand "impractical."

The key insight: the industry has mostly solved recording agent activity (OpenTelemetry's GenAI conventions, MCP logging, tamper-evident audit logs). What nobody had was an automated way to reconstruct what actually happened from that recorded evidence. That gap is what AgentTrace fills.

What AgentTrace does

AgentTrace is the investigation layer that sits downstream of the recorders. Point it at your evidence, and it:

Ingests 7 evidence sources into one normalized schema.
Verifies integrity + chain of custody — hash-chain verification, gap and witness-anchor detection, HMAC-signed manifests, and a tamper-evident custody ledger.
Reconstructs the causal attack chain across fragmented logs (timeline + provenance-style causal graph).
Detects 6 attack patterns, each mapped to a MITRE ATLAS technique and linked to the exact evidence: prompt injection via retrieval, exfiltration via tool chaining, OAuth/credential-theft chains, sub-agent hijack, memory poisoning, tool-permission escalation.
Builds kill-chain narratives and a 0–100 risk score.
Produces reports in JSON, Markdown, and self-contained offline HTML (with an SVG causal graph), including an EU AI Act Article 12 coverage section.
Exports portable, signed case bundles for air-gapped transfer.

Two design choices I won't compromise on

No AI/ML in the detection path. Every finding is deterministic and traces back to concrete evidence. A forensic tool has to be explainable — a model that says "I think this is an attack" does not survive a review, an audit, or a courtroom.

Local-first, zero dependencies. It runs fully offline on the Python standard library alone. No cloud, no account, no API key.

What it looks like in practice

pip install agentdfir

# What happened? Any known attack patterns?
agenttrace detect logs/*.json logs/*.jsonl

# Is the evidence trustworthy — altered or missing?
agenttrace verify logs/*.jsonl --signing-key "case-key" \
  --case-number "IR-2026-0042" --case-officer "A. Analyst"

# Produce a report for management / legal / a regulator
agenttrace report logs/*.json logs/*.jsonl --html-out report.html

On a synthetic multi-source incident, detect surfaces things like:

[CRITICAL] exfiltration_via_tool_chaining — 25 calls to 'crm_export' in 48s,
           monotonically increasing offsets  (MITRE ATLAS AML.T0057)
[CRITICAL] oauth_credential_theft_chain    — credential access -> rapid egress
[HIGH]     prompt_injection_via_retrieval  — poisoned chunk -> new sensitive tool

Each finding links to the exact events behind it, and the HTML report renders the whole story as a causal graph: poisoned document entered context → agent behavior shifted → credentials accessed → data left the building.

Chain of custody, everywhere

Forensic output is only useful if it holds up. Every stage — acquisition, verification, analysis, reporting, export, transfer — is written to a tamper-evident, hash-chained ledger attributed to a case officer, with tool version and timestamps. Reports and manifests are cryptographically bound to the exact evidence they were built from.

Try it / contribute

PyPI: pip install agentdfir
Repo: https://github.com/piyush295/agenttrace
Apache-2.0, offline, dependency-free.

I'd genuinely value feedback from anyone doing incident response on agentic systems — especially on the detection heuristics and which additional evidence sources are worth supporting next.

Authorized, defensive use only. AgentTrace analyzes evidence you are authorized to investigate; it is not an attack or surveillance tool.