Ways to decide what an agent may do
Once there are no screens, the rules the screens were holding have to be written down and put somewhere the agent cannot go around.
When an application had screens, the screens decided what anybody could do. Take the screens away, put an agent in front of the same system, and that decision has to be made somewhere else and written down. This group is about where policy lives once the interface stops holding it: what actually changes, where a rule can be applied, what the old permissions model was never built to answer, and how to avoid rebuilding a model somebody else already maintains.
Say it another way
What is policy, in plain words? It is the answer to who is allowed to do what, and when. In an ordinary application nobody had to write that down, because the screens answered it for them. You could only do what there was a button for. An agent has no screens. It can call anything it has been handed, in any order, as fast as it likes. So the rules that used to sit quietly inside the interface have to be said out loud, and put somewhere the agent cannot go around.
The pages in this group
- The forms were the policy. What the screens were quietly enforcing, and why nobody has the list written down.
- Three places a rule can live. In the form, once when it is set up, or at the moment of the call. What each one costs you.
- What permissions were never built for. Composition and context: the two questions roles and privileges cannot answer.
- Inherit the policy, do not rebuild it. Enforce it where it is already enforced, and the agent cannot exceed the person.
- Would the answer be the same next time?. The test that separates what a policy can settle from what only this person, this time, can answer.