Last week I wrote about a camera company that shipped tooling for an AI agent instead of a person. That post ended on a question I couldn't answer, and I've spent the days since chasing it. Here's where I've gotten to. I'm posting it because I don't think I can finish it alone.
The question is easy to ask and apparently hard to answer. When an agent takes an action inside a physical security system, what record does it leave behind?
What's actually shipping
This isn't hypothetical anymore. Rhombus published a workflow in July where an agent checks camera occupancy after hours, then calls a building management API to drop empty floors into energy-saving mode. Wowza launched a framework that fires downstream workflows off live video, model-agnostic, which is the sensible way to build it. Ambient put its agentic work around response and triage rather than detection. That's the honest place to put it.
Gartner's read at their risk summit was that agents move from alert triage toward autonomous investigation over the next 18 to 24 months, with high-risk actions staying human. Fine. In our world, high-risk means a lockdown and a dispatch.
The part we documented, and the part we didn't
Look at how we set an agent up. Context files describing the site. A tool manifest. Credentials, scopes, a list of what it may touch. It's the same package you hand a new employee on their first morning, and the industry got good at assembling it fast.
The Model Context Protocol shipped a major revision on July 28 that made this properly enterprise-grade. Stateless core, a governed extension system, authorization pulled into line with OAuth 2.0 and OpenID Connect. Real plumbing, built by serious people.
So authorization matured in under two years. Accountability didn't move at all.
The exhibit
In July, Genetec disclosed CVE-2026-55727: a flaw in the authentication mechanism for video stream requests in Security Center 5.14.0.0, which let an unauthenticated attacker reach live video before build 5.14.178.18. CVSS 7.5. They found it, fixed it, and published it, and I'd rather work with a vendor that does that than one that doesn't.
What sticks with me isn't the bug. It's that we are still getting authentication wrong for human clients, in mature products, in 2026. Now add a few hundred non-human clients holding API keys and working at 3 a.m. while nobody's watching.
What the guidance already says
On May 1, CISA and NSA published joint guidance with agencies from Australia, Canada, New Zealand, and the UK, called Careful Adoption of Agentic AI Services. It's the first coordinated multi-government guidance on agentic systems and it's short enough to read in one sitting.
It sorts the risk into five categories: privilege, design and configuration, behavioral, structural, and accountability. Accountability made the list on the first pass, which tells you the people writing it had already run into this. The guidance says to start with low-risk uses, expand autonomy as confidence grows, and design for reversibility and containment.
What it doesn't do is tell you what goes in the record. That's not a criticism. It isn't that kind of document.
What I couldn't find
I went and checked the standards bodies directly instead of trusting a search summary, because proving a negative from search results is exactly the move that makes you wrong in public.
ONVIF's published profiles are S, T, G, M, A, C, D, and V, and the newest one is about cloud video. PSIA publishes PLAI and PKOC. Neither has put out anything I can find on what record an autonomous action has to leave. NIST's agent work is a requirements backlog, not a control catalog. There's academic work, including a paper that proposes canonical action objects, approval binding, and receipt integrity. A paper isn't a profile.
If there's a working group on this that I've missed, say so and I'll go read it. I'd rather be wrong here than right.
The harder problem, which I only learned about because of license plate readers
In January, unredacted audit exports from a plate reader system exposed millions of queries along with details of active investigations. The vendor responded by masking the sensitive fields and making search reason and case number configurable in public exports. Oversight groups then reported that as reducing public accountability under the banner of transparency.
Both readings are fair. An audit record safe enough to publish is weaker for oversight, and one complete enough for oversight can't safely be published. As far as I can tell nobody has built one that does both jobs.
Agent receipts inherit that problem on day one. We are about to write audit logs for systems that make decisions, and the design question underneath them is still open. I don't think our industry has noticed.
What I'm doing about it, which isn't much yet
I've been working on a spec for agent action receipts. It's public, and it's independent of my day job. The goal is the smallest record that's actually useful: what was asked, what authority it ran under, what it touched, what it decided, what it declined to do, and a signature that survives being copied into somebody else's case file.
I don't know how to build the whole thing. I know what it has to survive, which is a different kind of knowledge and probably the less useful one.
It's wrong in places. That's why it's public.
So here's my question, and I mean it as a question rather than a setup. When an agent unlocks a door at 2 a.m., what is the smallest record that would satisfy three audiences at once: a judge, an insurer, and your own incident review the next morning?
I spent 21 years in law enforcement before this, and I sat through enough hearings to know the record of how evidence was handled decides cases about as often as the evidence does. I don't have a framework to sell anybody. I'd rather we work this out before a case works it out for us.
Teach me something in the comments.
I work in law enforcement business development at Alpha Vision. The receipts spec and this research are my own, independent of that work, and views here are mine.