Permission is not authority
Pick a process, then an action the agent attempts. Every one is permitted by the underlying system. Watch what runtime governance does with each.
- Purpose
- Acts alone up to
- With approval up to
- Accountable owner
Recorded: the objective, intent, action, the policy applied, the outcome and the reasoning behind it.
Illustrative and simplified. Names and limits are examples, not a client configuration.
Authorised access is not authorised behaviour
Take one agent. Using your own figures, see how much it could act on in a day if nothing stops it, and which controls narrow that most.
Whatever the systems it can reach would allow, in USD.
Payments, updates or approvals it could make.
The most you would let it do without a person, in USD.
What would narrow it most
Your figures stay in this browser. A worst case from what the agent can reach, not a forecast of loss.
Nothing executes outside the authority a person delegated
Where a bad outcome still occurs, it is because a person approved it, instructed it, or it fell inside the authority a person delegated. Each case is traced to that person, with the reasoning recorded.
Fails closed
If a check errors, or anything tries to go around it, the action does not execute.
Not replaced
Model validation, testing, data quality, and your existing identity, access and fraud controls.
Not included
The cost of the solution, delivery and operation. This is an illustration, not a quotation.
What that autonomy is worth in your exception queues
Governance is what lets agents take on the exceptions your rules could never automate. See the value in the STP savings calculator.
Find out what authority your agents actually have.
We will map one agent’s authority with your risk team and run it under runtime governance in your environment. Icebreaker is patent pending, with pilots and proofs of value in progress with regulated enterprises, and deploys on premises or in your cloud tenancy.