Pre-audit and transparent about it
Trust & Security by Design
Authorization controls, human accountability, and tamper-evident audit records for regulated workflows.
Section 1
Security architecture
Defense in depth, from how an agent proves who it is to how the data it touches is protected.
Authentication & authorization
- API authentication: a per-agent API key (stored only as a hash) or a short-lived OAuth 2.1 token on every call, over TLS
- OAuth 2.1: short-lived, scoped access tokens (client_credentials grant) as an alternative to long-lived API keys, bindable to a specific end user's consent
- Human approval: named approvers vote from their own login or a single-use emailed link, never with an API key. Each vote records who approved, their reason, and the device and IP address they approved from. An agent's credentials can't approve anything
- Step-up verification: a consent grant can require the end user to re-authenticate through their own institution's sign-in before it's issued, confirmed server-to-server, never trusted from a browser redirect alone
- Agent credentials: scoped to one agent and one environment. Revoking an agent blocks it on its next call; revoking a key blocks new tokens, and access tokens already issued from it expire within 10 minutes. Sandbox keys can't reach production
- Dashboard access: new accounts confirm their email; sessions can be ended on every device at once; sign-in is rate-limited
Agents don’t get blanket access. Each action requires proof of specific approval.
Encryption & data protection
- In transit: TLS 1.3, inherited from Vercel’s edge network
- At rest: AES-256 via Supabase-managed keys; uploaded documents are stored privately and served only to your signed-in account
- Audit logs: cryptographically sealed records with integrity checks; retention depends on your plan and agreed requirements
- Personal data: decisions don't need it: send opaque IDs rather than names or account details, since sealed audit records can't be edited later
Audit & evidence verification
- Tamper-evident trail: authorization decisions and supported review events submitted through Authentify are recorded
- Attribution: chain of custody from natural person → approval → action
- Timestamp evidence: eligible records can carry a signed timestamp for their evidence digest, showing that digest existed by the timestamp time
- Decision reasoning: every logged decision records why it was made: a matched authorization rule, by name, or the agent’s default scope
- Revocation history: full visibility into access removal and rescission
Infrastructure security
- DDoS protection: Vercel's platform mitigation, plus rate limits on sign-in and on every agent
- Behavioral monitoring: beyond a static per-minute ceiling, an agent's activity is compared against its own historical baseline: a pattern that's individually compliant but collectively anomalous gets flagged for review, not silently allowed
- Tenant isolation: every query is scoped to your account; row-level security is enabled on every table, so the database's public API exposes nothing
- Secrets management: encrypted Vercel environment variables, with a separate secret for each purpose (sessions, agent tokens, approval links, team logins)
- Uptime: served through Vercel's global edge network; availability is checked continuously and measured against your plan's SLA
- Browser protections: HSTS, anti-framing and a strict referrer policy on every page
Configurable authorization rules
Beyond static scope, banks define conditional rules that refine what an agent is allowed to do for a specific call: approve a payroll transfer under a dollar limit, cap the size of a sweep transfer, restrict an agent to a narrower action set for a given request. A rule can only narrow an agent’s existing access, never grant it more than its base scope allows, and every decision, whether a rule matched or not, is written to the audit trail with the reasoning behind it.
Example rule: payroll auto-approve
condition (AND): agentId === payroll-processor-v3 action === TRANSFER amount < 500000 scope override: allowedActions: [TRANSFER] amountLimit: 500000
Resulting audit log entry
result: AUTHORIZED
decision_reason: RULE_MATCHED
rule_name: "Payroll auto-approve"
applied_scope: {
allowedActions: [TRANSFER],
amountLimit: 500000
}Full field/operator reference and step-by-step setup: configure rules in your dashboard.
Section 2
Compliance & certifications
What's independently validated today, what we're building toward, and how responsibility is split contractually.
External certifications
- Vercel infrastructure: SOC 2 Type II (updated 2025), ISO 27001, GDPR Data Processing Agreement. SOC 3 report available on request. See Vercel's trust center
- Authentify application layer: targeting SOC 2 Type II audit in Q2–Q3 2027
- Pre-audit transparency: we’re building toward independent audit of our own application. The infrastructure we run on is already independently validated.
We’re built to the standards regulators are writing now, not after the fact.
Framework evidence mappings
- Compliance Coverage: recent audit events mapped to requirements in your enabled frameworks, with citations and supporting evidence
- Event evidence: inspect recorded decisions, attributed reviews, and seal verification; investigate missing evidence and integrity exceptions
- Review support: framework mappings are a crosswalk for evidence review, not a certification or a determination of regulatory applicability
- Your responsibility: organization-wide controls and legal obligations require evidence and assessment beyond an individual authorization event
- Independent timestamps: eligible sealed authorizations can carry downloadable FreeTSA witness evidence; the timestamp does not certify the decision or establish compliance
Data processing agreements
- Authentify’s role: data processor: you retain control
- Vercel’s role: infrastructure provider, shared security responsibility
- Your role: data controller: you decide the approval policy
- Hosting location: databases are hosted in the United States (AWS us-east-2, via Supabase)
Section 3
Trust architecture
The shared responsibility model, end to end, and exactly who owns each layer.
Your application
Agent, action execution
Their responsibility
Endpoint security and data handling in their own systems
Authentify API
Authorization, consent, audit logging
Authentify’s responsibility
Delegation logic, application controls, encryption at rest
Vercel + Supabase
Infrastructure
Shared responsibility
Network security, DDoS protection, database encryption
External APIs
Your domain systems and providers
Their responsibility
Endpoint security and data handling on their side
Read this diagram as a list
- Your application (Agent, action execution). Their responsibility: Endpoint security and data handling in their own systems
- Authentify API (Authorization, consent, audit logging). Authentify’s responsibility: Delegation logic, application controls, encryption at rest
- Vercel + Supabase (Infrastructure). Shared responsibility: Network security, DDoS protection, database encryption
- External APIs (Your domain systems and providers). Their responsibility: Endpoint security and data handling on their side
Responsibility matrix
| Layer | Authentify | Vercel | Supabase | Customer |
|---|---|---|---|---|
| API security | ||||
| Key management | ||||
| Audit trails | ||||
| DDoS / WAF | ||||
| Encryption at rest | ||||
| Access policies | ||||
| Incident response |
Section 4
Incident response & support
Incident notification
- Response SLA: critical incidents acknowledged within 4 hours
- Notification channels: email, and dashboard alerts for affected customers
- Post-incident reports: a written summary follows every confirmed incident
Support & questions
- Security contact: security@authentify.bz
- Vulnerability disclosure: email us directly. We do not yet run a public bug bounty program, but we credit and respond to every good-faith report.
Audit access
- SOC 2 Type II reports (once available) will be shared with customers under NDA
- Right-to-audit clause available in enterprise agreements
- Third-party penetration testing planned annually ahead of our SOC 2 audit
Section 5
Transparency commitment
- We log what you need to know; we don’t sell your data to third parties.
- You own your audit trail. It’s exportable, portable, and stays with you.
- We disclose our dependencies: Vercel, Supabase, and the external APIs agents call.
- We publish incident metrics: uptime, security patches, and response times.
- We’re pre-audit. We’re getting to SOC 2 Type II, and we’ll be transparent about the timeline the whole way.
Glossary
Audit trail
A record of authorization decisions and supported review events, with cryptographic seals that help detect changes to recorded evidence.
Authorization rule
A bank-configured condition that refines what an agent can do for a specific call; it can narrow an agent's access, never widen it beyond the agent's base scope.
Non-repudiation
Proof that a specific person made a specific decision at a specific time.
Out-of-band
Approval happens on a different device or channel than the one where the agent acts.
Shared responsibility
Authentify, Vercel, and Supabase each own parts of the security stack. The responsibility matrix above shows who owns what.
Ready to talk security?
Our security team responds directly. No ticket queue.