5 fields i wish i had on agent #1 i shipped: owner, scope, data flow, last reviewed, stop signal.
shipped a small agent six months ago that summarizes customer feedback. last week i went looking for which cloud holds its embeddings. could not tell you. mine. shipped it. forgot.
then nokod's survey landed sunday. 44% of enterprise ai agents visible to security. 56% invisible. mine was in the 56% until i sat down and filled in the row.
twenty minutes per agent on the first pass. mostly archaeology. every blank is a question you'd been getting away with not answering. owner field surfaced two agents whose owners changed roles. stop signal field forced me to test a kill switch i had not touched since january. one worked. one did not because an IAM key rotated and the runbook never got updated.
i'm keeping it as a single yaml file with a CI check that fails if last_reviewed is older than 90 days. three lines of action. the artifact is the audit.
what's the field you'd add to the 5?
6th field for me: PII redaction policy. Built a voice AI receptionist that handles calls + books meetings — first audit caught us logging full transcripts to a debugging cloud bucket with caller phone numbers in plaintext. GDPR-fatal if a regulator asked.
Fix: every transcript hits a redaction layer before storage. We log a hash of the phone number + timestamp, full audio is encrypted at rest with per-call keys. Stop signal got tested too — turns out our "hang up if caller says something flagged" rule was bypassed when the LLM hallucinated mid-sentence. Same lesson as your IAM key: assume your kill switch breaks until you test it.
The latency budget field is also worth tracking. We run under 800ms end-to-end and any new model swap that pushes past 1s degrades conversation quality fast. Caught it once when ElevenLabs added a new voice that added 300ms — would've shipped to prod without the field.
Three lines, one CI check, ridiculous ROI. Solid framework.
The missing one is blast radius.
Not what the agent does when it works. What it can touch when it fails.
Most teams log owner, scope, and data flow once the agent exists.
Very few force themselves to write down what this thing can overwrite, trigger, expose, or silently poison when it drifts.
That’s usually the field that turns “helpful automation” into “incident.”
Also worth saying: the YAML itself is the real product here.
Once an agent needs owner, stop signal, review cadence, and blast radius to stay deployable, it stops being a prompt wrapper and starts looking a lot more like infrastructure.
That shift is where most “AI tools” quietly become real software.
yeah, blast radius was on my draft list. cut it because i couldn't land on the scope definition. is it resource access? data sensitivity? probably deserves its own post.
It’s its own field.
Not “what can it access?”
What can it damage before anyone notices?
That’s the cleaner boundary.
Access tells you permissions.
Blast radius tells you consequence.
Two agents can have identical access and completely different failure cost.
That’s usually the line where “AI workflow” stops being a prompt problem and starts being software risk.
I’d definitely throw in a "Data Sensitivity Level" field. Knowing exactly which agents are touching PII versus just public feedback is the ultimate shield against a security nightmare, especially when you're moving at "vibe coding" speeds. That CI check for last_reviewed is a genius move it keeps your "agent archaeology" from becoming ancient history!
Beyond the broken kill switch, what was the most surprising "ghost in the machine" you found during your audit?
yeah, "gift to your future self" is the right frame. surprise audit hits and you're doing discovery in crisis mode without the row. added it.
that one's been sitting in my add-it-later pile forever. makes sense once you've got multiple agents hitting APIs and you genuinely can't answer what's touching PII here - gonna add it as field 6.
It’s a relief to see that "add-it-later" pile finally shrink! We usually build for speed, but Field 6 is really just a gift to your future self for when a surprise audit hits. Having that PII visibility is the only thing that keeps "vibe coding" from turning into a compliance nightmare