Product / How It Works
Out-of-band, biometrically confirmed authority for high-consequence execution.
The Control
One rule. Enforced deterministically.
GoFirm enforces one rule before any consequential action executes:
No confirmation, no action.
You could add friction to slow down and frustrate an attacker. Why not just make the attack impossible?
GoFirm is configured to stop actions in the defined categories until a designated authority provides a confirmed response. The designated authority confirms on their registered personal device with their biometric, via a channel separate from the system requesting the action.
Default failure behaviour: if GoFirm cannot reach the authority device or its own infrastructure, the action is stopped and the failure is logged. GoFirm does not fail open.
Architecture
Two layers. One permanent record.
GoFirm Core
Human-to-human workflows and AI agent actions. An initiator sends a GoFirm check. The designated authority confirms on their registered device. The action proceeds or is stopped.
Every event is signed and written to a permanent, append-only record.
No developer required for human workflows. Connect your HR directory, invite your people. Operational same day.
GoFirm Deep Guard
Control plane interception on sensitive resources: databases, secret vaults, identity providers, cloud IAM. An attacker or agent that bypasses the workflow layer reaches this one.
Every interception is logged to the same permanent record.
Deployed via the GoFirm SDK at the infrastructure control plane. Works alongside Core or independently.
Initiation
Three paths. One mechanism. One deployment.
The confirmation control fires from any workflow entry point. The underlying mechanism is identical regardless of source — human, agentic, or systems-initiated. Organisations that deploy GoFirm for one use case get coverage across all three simultaneously. No additional product, no additional integration, no additional cost.
An initiator opens the GoFirm app, selects a designated authority and action type, and submits a confirmation request.
An AI agent reaches a configured action threshold and calls goFirm.confirm() via the SDK before executing.
GoFirm Deep Guard intercepts at the control plane before the resource is accessed.
Configuration
Authority Registry
GoFirm uses your existing HR directory as its authority registry. Connect BambooHR, Workday, HiBob, Microsoft Entra, or Google Workspace. Alternatively, upload a CSV.
GoFirm does not store raw biometric data. Confirmation events are logged with identity references and timestamps. No biometric template or raw biometric input is retained on GoFirm servers. The HR directory remains the system of record for personnel identity.
Governance
Multi-Authority Confirmation
High-consequence actions can be configured to require multiple independent designated approvers before proceeding.
- One approver for a routine transfer
- Three for a sensitive data export
- Five for an irreversible system action
Any denial from any required approver stops the action. Configuration is per action type and managed from the admin panel.
How It Works
4 steps to a recorded confirmation — or a hard stop.
The same sequence fires regardless of initiation source.
The action is initiated
A payment is submitted. An AI agent reaches a configured threshold. A privileged access request is made. A production deployment is queued.
The action reaches a GoFirm confirmation gate. The gate fires regardless of initiation source: a human using the app, an AI agent calling the SDK, or GoFirm Deep Guard intercepting at the control plane.
The designated authority is notified
GoFirm identifies the authority assigned to this action type and sends a push notification to their registered personal device via a channel separate from the requesting system.
The notification contains the full action context: what is being requested, who initiated it, what payload is involved, and any relevant data classifications.
The authority confirms or declines
The authority opens the notification, reviews the context, and confirms with Face ID or fingerprint, or declines.
The device is physically registered and hardware-bound. The biometric confirmation is designed to resist remote compromise, credential theft, and social engineering of the confirmation step itself.
If the authority does not respond within the configured timeout, the action is stopped and the non-response is logged.
The verdict is enforced and recorded
Confirmed
The action proceeds. A signed, timestamped receipt is created and written to the permanent record. The approving authority is on record for that decision. The receipt is verifiable and non-repudiable.
Declined or no response
The action is stopped. The initiator or agent cannot retry. A named administrator with appropriate permissions can review the blocked action and reauthorise if needed. The full event is logged regardless of outcome.
When a regulator, an insurer, or a board asks who authorised an action, the answer is in the record.
Deployment
Deployment Boundaries
GoFirm operates as a confirmation layer within your existing workflows. It does not replace your identity, access, or monitoring infrastructure. It adds a deterministic human approval step at the execution boundary for the action types you configure.
Who administers GoFirm
A designated administrator within your organisation configures action types, assigns authority roles, and manages the authority registry via the admin panel.
What happens during connectivity loss
If GoFirm cannot reach the authority device or its own infrastructure, the default behaviour is to stop the action and log the failure. GoFirm does not fail open. Specific continuity protocols for critical operational environments are available at the enterprise tier.
What GoFirm does not govern
Routine, low-consequence, and reversible actions that fall below your configured thresholds pass through without interruption. GoFirm fires on the actions you tell it to.
Security & Compliance
The security model is the product.
Every constraint is architectural, not advisory.
Out-of-band confirmation channel
The confirmation channel is structurally separate from the action channel. A compromise of the requesting system does not give an attacker the ability to intercept, modify, or forge the confirmation request. The two channels do not share infrastructure.
Biometric device binding
Each authority registers a specific physical device. The confirmation requires a biometric on that device. The binding is at the hardware level, not the account or operating system level. Credential theft does not satisfy the confirmation.
Single-use confirmation per action
Each GoFirm request is tied to a single action instance and cannot be reused. This design addresses MFA fatigue attack patterns. Any subsequent attempt for the same action instance triggers an administrator alert.
Signed, permanent records
Each confirmation event produces a signed, timestamped receipt. Records are written to an append-only log. Entries are not modified or deleted by design. The record is intended to support non-repudiability.
Deterministic stops
GoFirm does not score, flag, or recommend. It stops configured actions until a human confirmation is received. No confirmation, no action, regardless of how the request was initiated or how legitimate the credentials appear.
Data minimisation
GoFirm does not store raw biometric data. No biometric template or biometric input is retained on GoFirm servers. Confirmation events are logged with identity references and timestamps. The HR directory remains the system of record for personnel identity.
Regulatory Alignment
GoFirm provides the implementation layer that compliance frameworks define but do not enforce. The mapping below shows how GoFirm's architecture relates to specific requirements across major frameworks.
This is provided as a reference for compliance and procurement conversations only. It does not constitute legal, regulatory, or compliance advice. Organisations should seek independent legal and compliance guidance before making regulatory claims based on GoFirm deployment.
| Framework | Requirement | How GoFirm addresses it |
|---|---|---|
| EU AI Act, Article 14 | Human oversight of high-risk AI decisions | Biometric human authority confirmation before AI-initiated consequential actions. Signed record of each oversight event. |
| NIS2 | Demonstrable controls on critical system access | Deep Guard intercepts at the control plane. Access to sensitive resources requires a confirmed authority decision. Each event is logged. |
| DORA | Operational resilience and audit trails on financial system actions | Append-only event log with signed receipts on every GoFirm action. Designed to support regulatory reporting and audit review. |
| ISO 42001 | AI management system controls and defined accountability | Named authority assignment, configurable action types, multi-authority enforcement, and a complete event log align with ISO 42001 control requirements. |
| NIST AI RMF | Governance, accountability, and human oversight of AI systems | GoFirm operationalises accountability requirements by ensuring each consequential AI action has an identified human authority on record. |