An agent preparing a report and an agent sending money should not inherit the same authority merely because both use an authenticated account. A human checkpoint is useful when the proposed action exceeds delegated authority or when the consequences require a responsible person’s decision under organizational policy.
A useful checkpoint makes the proposed action clear and keeps the application in control when execution occurs. The following illustrative workflow shows how preparation, permission and a human decision can work together.
Separate the actor from its authority
OWASP’s excessive-agency guidance distinguishes excessive capabilities, permissions and autonomy. An agent’s owner, workload identity, tools, data access and task limits belong in the design before an approval prompt is added.
Make the decision understandable
| Decision | Show the consequence |
|---|---|
| Context |
Show the recipient, amount, destination account, reason and requesting system where they matter to the decision. For a production-permission change, show the system, permission, duration and responsible owner. Choose the context and approval threshold around the consequence. |
| Attention |
A reviewer should be able to explain what will happen after approval. A generic request to confirm an identity is insufficient when the real question concerns disclosure, payment or privileged access. Excessive prompts can also erode attention; choose checkpoints according to consequence. |
Hold the operation until policy is satisfied
Correlate the result with the pending request and verify that the selected reviewer is authorized. Reject expired, stale or invalid results. Delivery of a notification is not consent. Silence, a device failure or a retry must not quietly become approval.
Where a supported NoPass checkpoint fits
The published sensitive-action flow describes an application holding an operation while NoPass™ requests a decision on the enrolled phone. The person compares the picture and number and accepts or declines. The application consumes the result under its own permissions and execution policy.
The FDA architecture and One AUTH Is Not Enough distinguish authentication from later authority. They support a focused integration discussion, not a claim of a generic agent-identity service, universal transaction signing or continuous policy enforcement by FDA.
Test the exceptions, not only the happy path
-
Test a wrong reviewer, a revoked device, altered details, duplicate responses, a late result and an unavailable phone. Demonstrate that the application still holds or refuses the operation. Test recovery without granting an unreviewed bypass.
-
Record the request reference, responsible reviewer, reviewed context, decision, expiry and execution result with an appropriate retention period. Do not put secrets or unnecessary personal information into analytics. Approval records support investigation; they are not conclusive proof of legal identity or intent.
Measure whether the checkpoint helps
Count completed decisions alongside declines, expiry and recovery. Observe whether reviewers can explain the requested action and distinguish an unexpected request. A high acceptance rate alone is not evidence of security or usable oversight.
Agent credentials, tool isolation, least privilege, anomaly monitoring and incident response remain separate controls. A human checkpoint can contribute to a wider architecture when its application boundary is real and tested.