Evidence that holds

Telling a control that works from one that has merely never been reached.

What does it mean for a capability to be implemented but never exercised?

It means the code exists and nothing has ever run it. Picture a permission check you wrote six months ago, on a path no request has taken since. It is implemented. It is unexercised. A code review will show it to you as a control. A coverage report will show it as a gap. Both are right. This matters because two very different states look identical from outside: a control that holds, and one that would fail the moment anything reached it. So ask what the last request down that path was, and when. If nothing can answer, you have your real state. It is unknown, not working.

What's the difference between an agent that can't do something and one that just hasn't?

One is a property of your system. The other is a property of your luck. An agent that cannot delete a record has no path to a delete: no credential, no route, no permission. An agent that has not deleted one has all three and has not been asked. From outside they look the same, and a log showing no deletions fits both equally well. This is the sharpest question you can ask about any agent behaviour someone calls safe. If the answer is that it has not happened, you have an observation. If the answer names what prevents it, you have a control.

How do I test that a guardrail holds, rather than that it exists?

Test the denial, not the permission. A test showing an authorised request succeed proves your happy path works. It says nothing about the guardrail, because that same test passes with the check deleted. The test carrying your evidence is the one where an unauthorised request is refused. It should fail loudly the moment somebody removes the control. Write one per boundary you claim. Then check the harder thing. Does your denial test reach the same code path a real request takes? A guardrail tested through a route production never uses is evidence about the route.

How do I know an agent's own evidence wasn't produced by the agent?

Look at what wrote the record. Evidence your agent generates about its own behaviour has the standing of a person's account of their own compliance. Worth having. Not independent. The test is whether the agent could have altered it. A log your agent writes through the same credential it acts with is not independent of the agent. A record written by infrastructure the call passed through, which the agent cannot modify, is. This gets sharper as agents produce more of their own documentation. Decide where you stand on it before somebody asks you.

How do I test an agent without a flaky test suite?

Test the boundary deterministically and the behaviour statistically. Do not mix them. Your permission checks, tool definitions and denial paths are ordinary code and deserve ordinary tests that pass every time. Those carry your evidence. Behaviour is a different exercise. Run a set, measure a rate, watch it across changes. Reporting that as pass or fail is what produces a suite people rerun until it goes green. Keep them in separate suites with separate names. A flaky test beside a real one teaches your team to ignore both.

What access should an agent have to its own logs?

Write access at the very least privilege you can manage, and preferably none at all. An agent that can read its own audit trail can be influenced by it. One that can edit it produces evidence about itself with nothing independent behind it. The arrangement you want is logging on the path your call travels, rather than in the agent. Then your record exists whether or not the agent cooperates. If it genuinely needs history, give it a separate working memory and keep your audit trail out of reach. Two stores, not one.