# AI agent security questionnaire: answer template From Authentify's guide: https://www.authentify.bz/ai-agent-security-questionnaire For each question, write your answer and list the evidence you can show. The hints describe what reviewers look for. Where you use Authentify, the "With Authentify" line states what the product does today; adapt it to your deployment. ## Scope and permissions _Commonly mapped to: SOC 2 CC6.1, CC6.3 · NIST AI RMF (Manage)_ ### 1. What actions can your agent take on our behalf? > They're asking: The blast radius. They want a finite, reviewable list, not "whatever the model decides". > 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. > > With 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. > Still yours: Deciding the list, and keeping it as short as the use case allows. **Our answer:** **Evidence we can provide:** ### 2. Which records, accounts or customers can it touch? > They're asking: Whether an agent working for one account could reach another’s data. > A strong answer includes: > - Scope enforced per call, at the record level. > - Out-of-scope attempts are blocked and surfaced, not silently ignored. > > With 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. **Our answer:** **Evidence we can provide:** ### 3. How do you enforce least privilege on each action, not just at login? > They're asking: Whether a session or token granted at the start gives the agent free rein afterwards. > 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. > > With 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. > Still yours: Calling Authentify before every consequential action, and acting only on "allow". Enforcement happens at your call site. **Our answer:** **Evidence we can provide:** ### 4. Can permissions differ for each of your customers? > They're asking: Whether their deployment is configured for them, or shares one global policy with your other clients. > A strong answer includes: > - Separate agents, credentials and scopes per customer deployment. > - Separate test and production environments. > > With 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. **Our answer:** **Evidence we can provide:** ### 5. How are permission changes made, approved and recorded? > They're asking: Change management: could someone quietly widen what the agent can do? > A strong answer includes: > - Named people can change permissions, through a controlled interface. > - Every change is recorded with who made it and when. > > With Authentify: 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. > Still yours: Keeping your own approval record for configuration changes (a ticket or change log) until Authentify records them itself. **Our answer:** **Evidence we can provide:** ## Human oversight _Commonly mapped to: EU AI Act Art. 14 · NIST AI RMF (Govern, Manage)_ ### 6. Which actions require human approval before they happen? > They're asking: Whether high-impact actions are gated, and whether the threshold is theirs to set. > A strong answer includes: > - Clear, configurable thresholds (amount, action type, resource). > - Escalation before execution, not review after the fact. > > With 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. **Our answer:** **Evidence we can provide:** ### 7. Who can approve, and how do you know they’re authorized to? > They're asking: Whether "approved" means a named, eligible person, or anyone with a login. > A strong answer includes: > - Named approvers with defined roles. > - Each approval tied to a specific person, with their stated reason. > > With Authentify: 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. > Still yours: Keeping operator email addresses accurate, and deactivating operators when people leave or change roles. **Our answer:** **Evidence we can provide:** ### 8. Can one person approve a high-risk action on their own? > They're asking: Separation of duties for the actions that matter most. > A strong answer includes: > - A configurable quorum of distinct approvers. > - The same person can’t count twice. > > With Authentify: 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. > Still yours: Restricting who can add operators, and reviewing the operator list when roles change. **Our answer:** **Evidence we can provide:** ### 9. What happens if nobody responds to an approval request? > They're asking: Whether a stalled approval fails safe, or quietly lets the action through. > A strong answer includes: > - Pending means not allowed: the action does not proceed on a timeout. > - Escalation or alerts when an approval is overdue. > > With Authentify: 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. > Still yours: An on-call rota so overdue approvals get picked up. **Our answer:** **Evidence we can provide:** ### 10. Can the agent act before approval arrives, or approve its own request? > They're asking: Whether the approval step can be bypassed by the thing it’s supposed to control. > A strong answer includes: > - The agent’s credentials can’t approve anything. > - The calling system holds the action until a final decision. > > With Authentify: 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. > Still yours: Holding execution in your application while the decision is "escalate". Authentify decides; your code must wait. **Our answer:** **Evidence we can provide:** ## Audit and evidence _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? > They're asking: Whether the log is complete, or only shows the happy path. > A strong answer includes: > - Every decision is recorded, including denials and escalations. > - Each record says why: which rule or limit applied. > > With 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. **Our answer:** **Evidence we can provide:** ### 12. Can the logs be altered after the fact? > They're asking: Whether the record would survive someone, including you, wanting to change it. > A strong answer includes: > - Append-only storage where any change is detectable. > - A way to show the chain is intact. > > With 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. **Our answer:** **Evidence we can provide:** ### 13. Can we verify the records ourselves, without trusting you? > They're asking: Independence. A vendor attesting to its own logs is weak evidence. > A strong answer includes: > - A verification method they can run. > - Timestamps from an independent third party. > > With 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. **Our answer:** **Evidence we can provide:** ### 14. How long are records kept? > They're asking: Whether evidence will still exist when an auditor or regulator asks for it. > A strong answer includes: > - A stated retention period that meets their requirements. > - An export path if they need to keep it longer themselves. > > With 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. > Still yours: Confirming the retention your customers’ regulators require, and exporting beyond it if needed. **Our answer:** **Evidence we can provide:** ### 15. Can you give our auditors evidence in a usable form? > They're asking: Whether they’ll get something an auditor can work with, or raw logs. > A strong answer includes: > - Exports organized around the frameworks they report against. > - Clear about what the evidence does and doesn’t prove. > > With 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. > Still yours: Framework mappings show supporting evidence. They are not a certification that your organization meets the framework. **Our answer:** **Evidence we can provide:** ## Identity and credentials _Commonly mapped to: SOC 2 CC6.1–CC6.3_ ### 16. How does the agent authenticate? > They're asking: Whether it uses a shared or long-lived secret that could leak. > A strong answer includes: > - A credential unique to each agent. > - Short-lived tokens where possible. > - Secrets stored hashed, never in plain text. > > With 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. **Our answer:** **Evidence we can provide:** ### 17. Can a credential be limited to less than the agent’s full permissions, or to one end user? > They're asking: Whether a leaked token would be as powerful as the whole agent. > A strong answer includes: > - Tokens narrowed to the task at hand. > - Tokens bound to the end user who gave consent. > > With 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. **Our answer:** **Evidence we can provide:** ### 18. How quickly can you cut an agent off? > They're asking: Time-to-contain if something goes wrong. > A strong answer includes: > - Immediate revocation of the agent and its credentials. > - A bounded window for anything already issued. > > With 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. **Our answer:** **Evidence we can provide:** ### 19. Could the agent change its own permissions? > They're asking: Privilege escalation by the agent itself, for example through a prompt injection. > A strong answer includes: > - The agent’s credential has no administrative rights at all. > > With 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. **Our answer:** **Evidence we can provide:** ## Data handling _Commonly mapped to: SOC 2 Confidentiality & Privacy criteria · GDPR Art. 5 (data minimisation)_ ### 20. What of our data does your authorization layer see? > They're asking: Whether adding a control layer means sending sensitive data to one more vendor. > A strong answer includes: > - Only the fields needed to make the decision. > - The customer controls exactly what is sent. > > With 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. **Our answer:** **Evidence we can provide:** ### 21. Where is that data stored, and how is it protected? > They're asking: Hosting, encryption and independent assurance. > A strong answer includes: > - A named hosting provider and region. > - Encryption in transit and at rest. > - Independent audit reports, or a timeline for them. > > With Authentify: 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. > Still yours: Deciding whether the current assurance level meets your customers’ requirements, and asking us for a security review if it needs discussing. **Our answer:** **Evidence we can provide:** ### 22. Can personal data be kept out of it entirely? > They're asking: Data minimisation, and how erasure requests would work. > A strong answer includes: > - Opaque identifiers instead of personal data. > - A clear answer on what happens to data that was sent. > > With Authentify: 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. > Still yours: Sending identifiers, not personal data, so erasure requests never touch the audit trail. **Our answer:** **Evidence we can provide:** ## Monitoring and incidents _Commonly mapped to: SOC 2 CC7.2–CC7.4 · NIST AI RMF (Manage)_ ### 23. How would you notice the agent behaving abnormally? > They're asking: Detection, not just prevention: what if the agent stays in scope but acts strangely? > A strong answer includes: > - Automated monitoring against a baseline. > - Alerts to a named person. > > With 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. **Our answer:** **Evidence we can provide:** ### 24. Is there a kill switch? > They're asking: Whether they can stop the agent immediately without waiting on you. > A strong answer includes: > - Instant revocation the customer can trigger. > - Automatic containment on clear violations. > > With Authentify: An agent can be revoked instantly from the dashboard or API. An out-of-scope attempt can revoke the agent automatically. **Our answer:** **Evidence we can provide:** ### 25. How are incidents recorded and resolved? > They're asking: Whether there’s a traceable record from detection to resolution. > A strong answer includes: > - An incident record with severity, timeline and resolution. > - Someone accountable for closing it. > > With 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. > Still yours: Your own incident process: who responds, and when you notify your customers. **Our answer:** **Evidence we can provide:** --- Framework references show where reviewers commonly file each question. They are guidance, not legal advice. Confirm mappings with your auditor or your customer's risk team.