If you sell an AI agent to a bank, insurer or health system, its risk team will send you a questionnaire before your agent is allowed to act. These are the 25 questions that come up again and again, what each one is really asking, and what an answer they’ll accept looks like.
In April 2026 U.S. bank regulators replaced their 2011 model-risk guidance with SR 26-2, which leaves generative and agentic AI outside its scope and to each bank’s own governance. So every bank now writes its own agent controls, and asks the vendors whose agents act inside its systems to meet them. Insurers and health systems face similar pressure from their own regulators and auditors.
How to read each question
What they’re really asking: the risk behind the wording.
What a strong answer includes: the evidence reviewers accept.
Where Authentify helps: what the product does today, marked Covered by Authentify, Partly covered or Your responsibility.
What stays with you: the part no control layer can do for you.
Honest scorecard: 18 covered, 6 partly covered, 1 your responsibility. Where Authentify falls short today, the answer says so.
Scope and permissions
What the agent is able to do, to which records, and who decides that.
Commonly mapped to: SOC 2 CC6.1, CC6.3 · NIST AI RMF (Manage)
1.What actions can your agent take on our behalf?
What they’re really asking
The blast radius. They want a finite, reviewable list, not "whatever the model decides".
What a strong answer includes
An explicit list of permitted actions per agent, not a description of the model’s capabilities.
Default-deny: anything not on the list is refused.
A way for them to see the list for their own deployment.
Where Authentify helps
Covered by Authentify
Each agent has an explicit list of allowed actions. Every call is checked against it before execution, and any action not on the list is denied and recorded.
What stays with you
Deciding the list, and keeping it as short as the use case allows.
2.Which records, accounts or customers can it touch?
What they’re really asking
Whether an agent working for one account could reach another’s data.
What a strong answer includes
Scope enforced per call, at the record level.
Out-of-scope attempts are blocked and surfaced, not silently ignored.
Where Authentify helps
Covered by Authentify
Each agent has a resource scope (an exact ID or a prefix pattern). Every call is checked against it. Out-of-scope attempts are denied, logged, and by default the agent is revoked automatically; alternatively it can be flagged for review.
3.How do you enforce least privilege on each action, not just at login?
What they’re really asking
Whether a session or token granted at the start gives the agent free rein afterwards.
What a strong answer includes
A check before each consequential action, not only at authentication.
Short-lived credentials that can be narrowed below the agent’s full permissions.
Rate limits so a runaway agent can’t act at machine speed.
Where Authentify helps
Covered by Authentify
Your application calls Authentify before each action and gets allow, deny or escalate. OAuth tokens last 10 minutes and can be narrowed to a subset of the agent’s actions. Per-agent rate limits apply on every call.
What stays with you
Calling Authentify before every consequential action, and acting only on "allow". Enforcement happens at your call site.
4.Can permissions differ for each of your customers?
What they’re really asking
Whether their deployment is configured for them, or shares one global policy with your other clients.
What a strong answer includes
Separate agents, credentials and scopes per customer deployment.
Separate test and production environments.
Where Authentify helps
Covered by Authentify
Register a separate agent per customer deployment, each with its own key, actions, scope, limits and approvers. Sandbox and production run on strictly separate databases: each key and each login reaches only its own environment, so test traffic can never touch production records.
5.How are permission changes made, approved and recorded?
What they’re really asking
Change management: could someone quietly widen what the agent can do?
What a strong answer includes
Named people can change permissions, through a controlled interface.
Every change is recorded with who made it and when.
Where Authentify helps
Partly covered
Changes are made by your account’s administrators in the dashboard or through the API. Agents’ own keys cannot change their configuration. Configuration changes are not yet written into the tamper-evident audit chain.
What stays with you
Keeping your own approval record for configuration changes (a ticket or change log) until Authentify records them itself.
Human oversight
Which actions a person must approve, who that person is, and what happens when nobody answers.
Commonly mapped to: EU AI Act Art. 14 · NIST AI RMF (Govern, Manage)
6.Which actions require human approval before they happen?
What they’re really asking
Whether high-impact actions are gated, and whether the threshold is theirs to set.
Escalation before execution, not review after the fact.
Where Authentify helps
Covered by Authentify
For financial actions you set an autonomy ceiling and eligible transaction types; anything above it is escalated. In other domains, actions that pass the scope checks are escalated to human review by default. An agent can also be set to require approval for everything.
7.Who can approve, and how do you know they’re authorized to?
What they’re really asking
Whether "approved" means a named, eligible person, or anyone with a login.
What a strong answer includes
Named approvers with defined roles.
Each approval tied to a specific person, with their stated reason.
Where Authentify helps
Partly covered
Approvers are registered as named operators with roles, and an agent can require specific roles to approve. Each vote is cast by that person, either through a single-use approve/reject link emailed only to them or from their own dashboard login, which opens straight to their approval queue. Each vote records their role, a typed attestation and their reason. API keys can’t cast votes.
What stays with you
Keeping operator email addresses accurate, and deactivating operators when people leave or change roles.
8.Can one person approve a high-risk action on their own?
What they’re really asking
Separation of duties for the actions that matter most.
What a strong answer includes
A configurable quorum of distinct approvers.
The same person can’t count twice.
Where Authentify helps
Partly covered
Each agent can require a quorum of approvers. The same operator can never be counted twice toward it, and each vote has to come from that operator’s own link or login. The account owner registers operators, so separation of duties also depends on who controls that account.
What stays with you
Restricting who can add operators, and reviewing the operator list when roles change.
9.What happens if nobody responds to an approval request?
What they’re really asking
Whether a stalled approval fails safe, or quietly lets the action through.
What a strong answer includes
Pending means not allowed: the action does not proceed on a timeout.
Escalation or alerts when an approval is overdue.
Where Authentify helps
Partly covered
A request stays pending until it’s approved or rejected, so the agent never proceeds by default. Eligible approvers are emailed when a request escalates, again at 75% of the SLA window, and when it’s breached, each time with single-use approve/reject links. Automatic re-routing to backup approvers isn’t available yet.
What stays with you
An on-call rota so overdue approvals get picked up.
10.Can the agent act before approval arrives, or approve its own request?
What they’re really asking
Whether the approval step can be bypassed by the thing it’s supposed to control.
What a strong answer includes
The agent’s credentials can’t approve anything.
The calling system holds the action until a final decision.
Where Authentify helps
Partly covered
An agent’s own credentials are rejected by the approval, configuration and consent endpoints, so an agent can’t approve its own escalations or widen its own limits. Authentify returns "escalate" until the quorum is met, and a revoked agent’s pending requests can no longer be approved.
What stays with you
Holding execution in your application while the decision is "escalate". Authentify decides; your code must wait.
Audit and evidence
Whether there is a complete, trustworthy record, and whether they can check it themselves.
Commonly mapped to: EU AI Act Art. 12 · SOC 2 CC7.2 · NIST AI RMF (Measure)
11.Is every agent action logged, including the ones you blocked?
What they’re really asking
Whether the log is complete, or only shows the happy path.
What a strong answer includes
Every decision is recorded, including denials and escalations.
Each record says why: which rule or limit applied.
Where Authentify helps
Covered by Authentify
Every authorization call is recorded: the agent, action, resource, outcome, the reason, any matching rule, and latency. Approval votes are recorded as their own events, and so is each reported outcome: what happened after the action ran, who reported it (the institution’s own system or the agent), and, where the institution signs its reports, a verified signature.
12.Can the logs be altered after the fact?
What they’re really asking
Whether the record would survive someone, including you, wanting to change it.
What a strong answer includes
Append-only storage where any change is detectable.
A way to show the chain is intact.
Where Authentify helps
Covered by Authentify
Records are sealed into a hash chain: each record’s seal depends on the one before it, so editing or removing any record breaks the chain at that point.
13.Can we verify the records ourselves, without trusting you?
What they’re really asking
Independence. A vendor attesting to its own logs is weak evidence.
What a strong answer includes
A verification method they can run.
Timestamps from an independent third party.
Where Authentify helps
Covered by Authentify
The chain can be re-verified at any time, and the check reports exactly which record breaks it, if any. Decisions can also be timestamped by an independent RFC 3161 timestamp authority and checked on a public verification page.
14.How long are records kept?
What they’re really asking
Whether evidence will still exist when an auditor or regulator asks for it.
What a strong answer includes
A stated retention period that meets their requirements.
An export path if they need to keep it longer themselves.
Where Authentify helps
Covered by Authentify
Records are kept for at least 90 days on the Growth plan and at least 1 year on Scale. Enterprise retention is set by contract. Records can be exported at any time.
What stays with you
Confirming the retention your customers’ regulators require, and exporting beyond it if needed.
15.Can you give our auditors evidence in a usable form?
What they’re really asking
Whether they’ll get something an auditor can work with, or raw logs.
What a strong answer includes
Exports organized around the frameworks they report against.
Clear about what the evidence does and doesn’t prove.
Where Authentify helps
Covered by Authentify
PDF exports organized for SOX 404, NYDFS Part 500 and the EU AI Act, plus a compliance-coverage view mapping each event to framework requirements. Independent timestamp evidence can be downloaded per decision.
What stays with you
Framework mappings show supporting evidence. They are not a certification that your organization meets the framework.
Identity and credentials
How the agent proves who it is, and how fast that can be taken away.
Commonly mapped to: SOC 2 CC6.1–CC6.3
16.How does the agent authenticate?
What they’re really asking
Whether it uses a shared or long-lived secret that could leak.
What a strong answer includes
A credential unique to each agent.
Short-lived tokens where possible.
Secrets stored hashed, never in plain text.
Where Authentify helps
Covered by Authentify
Each agent gets its own API key, stored only as a hash. For short-lived credentials, the agent exchanges it for OAuth 2.1 access tokens that expire after 10 minutes.
17.Can a credential be limited to less than the agent’s full permissions, or to one end user?
What they’re really asking
Whether a leaked token would be as powerful as the whole agent.
What a strong answer includes
Tokens narrowed to the task at hand.
Tokens bound to the end user who gave consent.
Where Authentify helps
Covered by Authentify
OAuth tokens can be issued for a subset of the agent’s actions, and bound to a specific end user. A bound token only works while that end user’s consent is active, and can’t be used for any other user.
18.How quickly can you cut an agent off?
What they’re really asking
Time-to-contain if something goes wrong.
What a strong answer includes
Immediate revocation of the agent and its credentials.
A bounded window for anything already issued.
Where Authentify helps
Covered by Authentify
Revoking an agent or key takes effect on the next call. Access tokens already issued expire within 10 minutes. Pending approvals for a revoked agent can no longer be approved. Dashboard sessions can also be ended on every device at once.
19.Could the agent change its own permissions?
What they’re really asking
Privilege escalation by the agent itself, for example through a prompt injection.
What a strong answer includes
The agent’s credential has no administrative rights at all.
Where Authentify helps
Covered by Authentify
Agent credentials only work for authorization checks, exchanging for short-lived tokens, and reporting their own outcomes (an institution can refuse those and accept outcomes only from its own system). They are rejected by every administrative, approval and consent endpoint.
Data handling
What the control layer sees, where it lives, and how to keep sensitive data out of it.
20.What of our data does your authorization layer see?
What they’re really asking
Whether adding a control layer means sending sensitive data to one more vendor.
What a strong answer includes
Only the fields needed to make the decision.
The customer controls exactly what is sent.
Where Authentify helps
Covered by Authentify
Only what your application sends: the action, a resource ID and type, any context fields your rules use (such as an amount), and optionally an end-user ID. Authentify never connects to your systems or data.
21.Where is that data stored, and how is it protected?
What they’re really asking
Hosting, encryption and independent assurance.
What a strong answer includes
A named hosting provider and region.
Encryption in transit and at rest.
Independent audit reports, or a timeline for them.
Where Authentify helps
Partly covered
Authentify runs on Vercel, with Postgres on Supabase. All traffic is encrypted with TLS, including connections to the database, and documents you upload are stored privately and served only to your signed-in account. Architecture and the security programme are described on the Trust & Security page, and every subprocessor is listed in section 4 of the Privacy Policy. Authentify’s own SOC 2 Type II audit is planned for Q2–Q3 2027.
What stays with you
Deciding whether the current assurance level meets your customers’ requirements, and asking us for a security review if it needs discussing.
22.Can personal data be kept out of it entirely?
What they’re really asking
Data minimisation, and how erasure requests would work.
What a strong answer includes
Opaque identifiers instead of personal data.
A clear answer on what happens to data that was sent.
Where Authentify helps
Your responsibility
Yes. Send opaque IDs rather than names or account details; decisions don’t need personal data. Note that sealed audit records can’t be edited later, which is what makes them trustworthy, so anything you send becomes part of the permanent record.
What stays with you
Sending identifiers, not personal data, so erasure requests never touch the audit trail.
Monitoring and incidents
How misbehavior gets noticed, stopped and written up.
Commonly mapped to: SOC 2 CC7.2–CC7.4 · NIST AI RMF (Manage)
23.How would you notice the agent behaving abnormally?
What they’re really asking
Detection, not just prevention: what if the agent stays in scope but acts strangely?
What a strong answer includes
Automated monitoring against a baseline.
Alerts to a named person.
Where Authentify helps
Covered by Authentify
Every 15 minutes each agent’s recent activity is compared with its own 7-day baseline, and anomalies open an incident and send an alert. Per-agent denial rates are tracked too.
24.Is there a kill switch?
What they’re really asking
Whether they can stop the agent immediately without waiting on you.
What a strong answer includes
Instant revocation the customer can trigger.
Automatic containment on clear violations.
Where Authentify helps
Covered by Authentify
An agent can be revoked instantly from the dashboard or API. An out-of-scope attempt can revoke the agent automatically.
25.How are incidents recorded and resolved?
What they’re really asking
Whether there’s a traceable record from detection to resolution.
What a strong answer includes
An incident record with severity, timeline and resolution.
Someone accountable for closing it.
Where Authentify helps
Covered by Authentify
Incidents opened by the anomaly detector are recorded with severity and reason, and resolved with notes and the name of whoever resolved them. Resolved incidents count as evidence in compliance coverage.
What stays with you
Your own incident process: who responds, and when you notify your customers.
Framework references show where reviewers commonly file each question. They are guidance, not legal advice, and supporting evidence is not a certification. Confirm mappings with your auditor or your customer’s risk team.
Answer these with evidence, not promises
Put your agent behind an authorization check in the free sandbox, then point your customer’s reviewers at real, verifiable decisions.