It counts when your human can stop the action, and the system records that they could. Three things separate a control from a screenshot. The action must not proceed without approval. That makes it enforcement, not notification. Your approver needs enough on screen to decide, because approving what you cannot see is a rubber stamp with a name on it. And the decision must be recorded against the action, so a reviewer can join the two later. A confirmation dialogue that defaults to yes and logs nothing fails all three. In your demo it will look exactly like a control.
Related: How should I log agent actions so the log is usable as evidence later?, How do I test that a guardrail holds, rather than that it exists?
Reuse the enforcement. Re-examine the assumptions. If your controls sit at the data boundary and decide from a verified caller, an agent is just another caller. Your evidence extends to it without ceremony. That is the good case, and it is a common one. What breaks are your assumptions about rate and intent. Controls designed around a human's pace. Controls where a review step assumed somebody was reading. Anything treating a session as a proxy for a person. Go through your controls and ask which would still hold if the caller were a thousand times faster and never got bored.
Related: How do I prove an AI agent can't exceed the permissions it was given?, What does human-in-the-loop have to look like before it counts as a control?
A way to stop it, and a way to find what it touched. Those are the two things a human-shaped plan assumes and your agent breaks. Stopping means a kill path you have tested. Revoke the credential. Disable the tool. Halt the loop. Not a code change and a deploy. Blast radius means your logs answer what the agent called, with whose authority, across the whole window. Then add a line your existing plan will not have. Who decides it goes back on, and what do they check first?
Related: How should I log agent actions so the log is usable as evidence later?, How do I keep a human able to intervene in a long-running agent task?
Show it refusing, not merely configured. A rate limit is a control like any other, so your evidence takes the same shape. It exists. It sits on your path. It denied something. That denial is the part nobody keeps. Log your rejections with the identity and the window. A limit that has never fired looks identical to one that is not wired up. Rate limits matter more for your agent than for your users, for an obvious reason. It does not get tired, and a loop that would take you a week takes it a minute.
Related: How do I test that a guardrail holds, rather than that it exists?, Can I reuse the access-control evidence I already have for agent actions?
Give the task a state your people can read and a control they can press. A long run fails differently from a request. Nobody is watching, and by the time you look the work is done. So expose where it is, what it has done, and what it will do next. Make your stop synchronous. Pressing it halts the next action rather than filing a request to halt. Checkpoint, so stopping does not lose everything. If what it will do next is unavailable, your run is not observable and stopping it is guesswork.
Related: What does human-in-the-loop have to look like before it counts as a control?, What belongs in an incident response plan when the actor is an agent?
You can, and it becomes a processing activity with everything that implies. Evaluation feels like testing and looks like production to your data. If real records go through it, your access rules apply. Who sees results, where they are stored, how long they live. Two things go wrong. Evaluation sets get copied somewhere with weaker controls than the system they came from. And results get kept forever, because nobody set a retention on a scratch directory. Decide both before you start, not after somebody asks what is in that bucket.
Related: How do I evidence deletion when an agent may have copied the data?, How do I evidence that one tenant's data never reached another tenant's agent?