My First Conference Talks: KubeCon India and Open Source Summit India 2026

tl;dr: Always keep a recorded demo. 😅

In June 2026 I gave my first two conference talks, in the same week, in Mumbai:

• Open Source Summit India 2026: “Oops, My AI Agent Just Deleted All My Email: Locking Down Agents with Signed Policies”
• KubeCon + CloudNativeCon India 2026 (Maintainer Track): “in-toto Attestations for What Really Happens in Your Build Pipeline, with Witness”, with Vyom Yadav (Canonical)

I was still in college, interning at HighLevel and working on supply chain security with TestifySec on the side. TestifySec fully sponsored the trip. It was four days of talks, hallway conversations and very little sleep.

Talk 1: Locking down AI agents with signed policies

AI agents now run shell commands, edit code and call APIs on your behalf. When one of them goes wrong, for example deleting a repository, leaking a .env file or calling a URL it shouldn’t, there’s usually no proof of what it actually did.

That’s what aflock is for. The mental model:

package-lock.json locks your dependencies. .aflock locks what your AI agent is allowed to do.

The policy says which tools, files and domains the agent may use, and with what limits. It is signed, so the agent can’t quietly rewrite it.

In the demo, the policy allowed Read, Edit, Bash, Glob and Grep, denied WebFetch, allowed files under src/** and tests/**, and denied **/.env. When the agent tried to read the env file or reach an external URL, it got a DENY.

How it works under the hood:

1. The signed .aflock policy is loaded and verified by the aflock server, the policy decision point.
2. At session start, the agent gets a JWT describing what it may do. Its identity is a hash of model, environment, tools, policy digest and parent.
3. Every tool call is gated. Allowed calls run. Denied calls never execute.
4. Every call is signed, allow and deny alike, by a key the agent never sees, with the signer identity rooted in a SPIRE SVID.
5. The receipts are in-toto attestations (DSSE), merkle-chained per session, and aflock verify re-checks the whole chain later.

The key idea is that denials get signed too. Afterwards you can prove both what the agent did and what it tried to do.

📺 Recording: youtube.com/watch?v=ChNC3HN5Nsk · Schedule

What went wrong (and what saved me)

The live demo didn’t work. I had a recorded backup ready, so I switched to it and kept going. That recording saved the talk.

I was nervous. It was my first talk ever, and my manager, Raveesh Agarwal, was in the audience. His advice before I went up:

Slow down. Don’t rush. If you fumble, pause and continue.

My session was right after lunch, so I finished eating early and spent time on the empty stage: checking the clicker, the screen and the mic, and getting used to the room. That calmed the nerves more than anything else.

Talk 2: in-toto attestations with Witness (KubeCon Maintainer Track)

Two days later, Vyom Yadav (Canonical) and I presented on the Maintainer Track at KubeCon India. We split the talk in two: I set up the problem, up to the in-toto attestation framework, and Vyom took it from there with Witness, eBPF, SBOMit and the demo.

My part: why we need attestations

Do you know what your build actually did? We review the inputs (source code, the dependency list), but the build itself runs unwatched. It spawns processes, opens files and makes network calls, sometimes to an unknown host.

When we don’t know, we get burned. With Log4Shell (CVE-2021-44228), the real damage was that most organisations couldn’t tell whether they even used log4j. It was buried as a transitive dependency, and teams spent days just finding out if they were exposed. A good SBOM turns that into a query: found, version 2.14.1, vulnerable, 3 services, 2 teams, answered in minutes instead of days.

But can you trust your SBOM? Where traditional SBOMs break:

• A: an attacker compromises the VCS and inserts unsigned code
• B: testing failed, or the testing step is missing entirely
• C: the compiler itself is hacked (SolarWinds, XcodeGhost)
• D: SBOMs from different vendors have blind spots
• E: attackers counterfeit or forge the SBOM

What we actually need is the full story: who did what, when, and with what input. That’s where in-toto comes in.

An attestation is a signed statement bound to one artifact:

• subject: which artifact, identified by its hash
• predicate: what happened (files, network, …)

It’s evidence anyone can verify, not a log file you have to trust.

The in-toto Attestation Framework puts it together: a DSSE envelope wraps a Statement with a subject (name and digest) and a typed predicate, which can be an SPDX SBOM, SLSA provenance or anything else.

Vyom’s part: Witness, eBPF and SBOMit

Then came the twist: “Wait… accurate SBOMs?”

Witness monitors the actual build. Wrap your build in witness run --step build -- make … and it records processes spawned, files accessed, git commits, environment and network calls as signed attestations. It ships dozens of attestors (git, environment, SLSA, SBOM, OCI, k8s manifests, a network trace and more).

Under the hood, Witness uses ptrace and eBPF to watch the build from the kernel:

• Files and processes: hooks on sys_enter/sys_exit for open and on sched exec/exit stream events through a ring buffer to Witness.
• Network: a cgroup/connect4 TCP hook saves the original destination and transparently reroutes the connection through a MITM proxy, which sends telemetry to Witness.

Finally, SBOMit = SBOM + in-toto: take an ordinary SBOM, add the Witness attestation collection from the real build, and you get an enriched SBOM backed by evidence of what actually ran.

Vyom closed with a live demo and an honest limitation. With many inputs mapping to many outputs (sources → binaries → .deb packages), tying each output back to its exact inputs is still hard.

📺 Recording: youtube.com/watch?v=NL02NnmrE4o · Schedule

Want to get involved? in-toto holds a community meeting on the first Friday of every month. Join #in-toto and #in-toto-witness on CNCF Slack and #sbomit on OpenSSF Slack, or start at github.com/in-toto/witness.

The hallway track

The best part of a conference happens outside the talks. I had long conversations about AI agents, SBOMs, eBPF, observability and software supply chain security with people who work on these problems every day.

I also got a selfie with Daniel Krook. 😅

And yes, I came home with a lot of swag.

A bit of Mumbai

Between sessions I explored Mumbai: CSMT lit up at night, the sea and the Taj.

What I’d tell a first-time speaker

1. Always keep a recorded demo. Live demos fail, so have a backup video ready.
2. Get on stage early. Ten minutes on the empty stage before your slot calms you down.
3. Slow down. If you fumble, pause, breathe and continue. The audience is on your side.
4. Submit even if you feel “not ready”. I was a student intern, and both talks got in.
5. Talk to people. The hallway conversations are worth as much as the talks.

Thank you

• Cole Kennedy and TestifySec for sponsoring the trip. Cole started aflock, and contributing to it has been an incredible learning experience.
• Vyom Yadav for co-presenting at KubeCon and for all the in-toto work together.
• Raveesh Agarwal for the advice and for showing up in the audience.
• The Linux Foundation and CNCF teams for running both events.

Since then I’ve become a maintainer of in-toto Witness, and I’m submitting talks for 2027. If you were at either talk, or want to chat about AI agent security or supply chain attestations, say hi on X or LinkedIn.

Originally shared on LinkedIn and X.