Authentication vs action authorization
Being recognized is not the same as being permitted to take a consequential action.
Direct answer
Authentication establishes identity. Action authorization decides whether that identity may perform this action, on this target, under current policy and conditions.
Does a successful login authorize an agent's next payment?
No. A recognized identity is an input to authorization. The proposed payment still needs delegated authority, applicable policy and current evidence. Keep the identity decision distinct from the business-action decision and enforce both at the relevant boundary.
Worked benchmark example
Compare C and D: invalid authority caused DENY for the USD 1,500 proposal; valid authority did not bypass the human-approval requirement for USD 900. In each case the mock API remained untouched.
What to ask in an evaluation
Ask which principal delegates authority, what limits apply, and what happens when approval is missing.
Why it matters
Treating login as blanket permission creates a gap between access and consequence.
Concrete cross-sector example
A signed-in treasury user may view payment records but cannot change a beneficiary or release a payment without action-specific authority.
Control flow
Authenticate identity → load delegated authority → specify proposed action → evaluate current conditions → authorize or stop
Applicable Prudenze capabilities
Arkon · Guardian
Evidence and research
Link the authenticated identity to the delegation, action, target, policy decision and final outcome.
Source: local OpenShell qualification, scenarios C and D. These are deterministic fixtures and a mock payment API, with no customer systems or real payments.
Read all seven results, pinned versions and reproduction stepsPrudenze is a Hyperwise LLC product. This article is published by the Hyperwise team. About Hyperwise.