Agentic guidance: SSEM already carries most of it, re-asked against actions rather than code

[Mayur021]

Took up the read-one-section ask. The section I landed on is 7.1.2, and the observation is about what is not there rather than what is.

"Agentic" appears three times in the framework, at 7.1.2 and 8.1.1, and in every case it means tooling that assists the security team. Capacity relief, degraded-mode compensation. It never means software the framework is being asked to govern. Since the roadmap names agentic guidance as planned work, this is a note about where that might attach, and my argument is that it needs less new material than it looks like.

Three SSEM attributes already carry it once you re-ask them against actions the software takes on its own, which is the same move 4.6 makes when it re-asks the 4.5 selection criteria against time.

POLA, 2.7. The section already asks for functions and methods that do what their names indicate, without hidden side effects. For an agent the unit is the tool contract, and that contract is usually a name and a description written by whoever built the tool. A tool called list_invoices that also marks them as viewed is a POLA violation in exactly the sense 2.7 means. What differs from the human case is that a developer reading that function can be astonished and an agent cannot. It plans against the description, so an inaccurate description is not a documentation defect. It is the input to the decision.

Resilience, 3.2.3.3, and the phrasing already in 4.6. Stewardship asks for a current answer, not a historical one, for what happens if a dependency is abandoned or compromised. The same question asked against actions is whether there is a current answer for undoing what the action did. Some actions have one, some have never had one, and that difference is a property of the action rather than of the code quality around it. It survives the code being excellent.

Accountability, 3.2.2.2. An action taken with nobody in the loop still has an accountable party, and which party that is tends to be undefined at exactly the moment it matters.

I want to be clear about what I am not proposing, because 6.1 is right and I would rather not walk straight into it. This is not a control, not a requirement, and not a gate. It is an attribute question of the kind a merge review can already ask, which sits fine with the advisory default in 5.2.2 and leaves gating where 5.2.3 leaves it, as a policy decision the organisation makes rather than one the framework makes on its behalf.

On the relationship to #20, which I read before writing this. Gautam's object is the dependency you selected and whether its contract still says what it said. Mine is the call the running system makes and whether the contract was ever an honest description of the effect. They compose rather than overlap. His tells you the description changed; this one asks whether the description was accurate when you accepted it. A tool can be perfectly stable and perfectly misdescribed.

Three places it might attach, if any of it is useful. A paragraph in 2.7 extending least astonishment to declared tool contracts. The undo question under Resilience, or alongside the least-privilege paragraph in 4.4. And a line in Appendix A, since "can this action be undone, and by whom" is answerable without a scanner.

Happy to draft any of that as a PR if it is worth having, and happy to review the agentic coverage in the SSEM Primer when it is ready.

Disclosure: I work on action governance for autonomous agents and maintain an open reference implementation in that area, so I have a standing interest in the topic. The POLA point is not theoretical for me. The gap between a declared effect and a verified one is an open item in my own code, which is part of why I think it belongs in an attribute model rather than a control list.

[gautamgb]

The action-reversibility point is the piece neither 4.5 nor my #20 can carry - it's a property of the action, not the dependency. Worth its own subsection.