4SI for institutions
Move faster.
Keep control.
Money moves. Doors open. AI agents act. We’re building Presence to connect these decisions to the people and objects they depend on.
Why Presence
The moment before
Your next decision
has real consequences.
A payment can be hard to recover. Access can expose a critical system. An automated action can commit your organisation before anyone has a chance to intervene.
The question is practical: what must be true before this action is allowed to happen?
The evidence gap
The account is valid.
Who is actually there?
Your systems establish accounts, permissions and approval rules. Some decisions also depend on a physical fact: a particular person is present, or a particular item is the one you expect.
A convincing message, a valid session or a matching record may leave that question open. Presence is designed to add evidence about the person or object at the moment it matters.
How this fits with identity and security controls
The starting point is your existing control environment. Identify the physical condition it needs to establish, and whether current controls already establish it. A Presence evaluation should demonstrate incremental value for that specific gap.
Presence does not replace identity enrolment, authorisation, cryptography, fraud controls or compliance. Physical presence alone does not establish that an instruction is legitimate or that a person understands it.
One physical step.
Inside your workflow.
For people, the intended experience starts with a personal Key. The person activates it locally, presents it to a compatible reader, and continues in your service.
- 01
You define the moment.
Name the action, the person or object to check, and the evidence your policy requires.
- 02
Presence checks.
A compatible reader and the platform connect the physical check to that request.
- 03
Your system decides.
The result supports your decision. Your permissions, limits and approval rules remain in force.
The Key stays offline.
Reader and platform connect to your systems.
Start where
it matters most.
Choose a moment where the consequence justifies a physical check. These are the workflows we want to evaluate with institutions.
Before money moves.
A payment fits the rules. The instruction looks familiar. Your process still needs to establish that the designated person is involved in this approval.
Add a Presence check at the approval threshold you define. Keep payment limits, dual approval and the payment provider’s controls in place.
What would we evaluate?
Whether the check is bound to the correct amount, payee and approver; how long approval takes; and what happens when verification fails.
Before access is granted.
A facility opens. A sensitive system becomes available. The permission is valid—but your workflow may also require the expected person to be physically involved.
Bring a physical check to a defined access or privileged action. Your access policy continues to decide who may proceed.
What would we evaluate?
Verification performance in the actual setting, completion time, lost-Key recovery, availability and supervised exceptions.
Before an agent commits.
An agent can prepare a payment, change a system or act on a customer’s behalf. Decide which actions it may take alone—and where a named person must confirm.
Use Presence as a proposed physical confirmation step at that boundary. Connect the person’s confirmation to the specific action your agent is allowed to execute.
Where does human oversight end?
Physical presence is one part of oversight. The person still needs to understand the action; the system still needs limits, revocation and a safe way to stop. Evaluation tests that whole chain.
Before an item is trusted.
A record identifies a component. A certificate describes its origin. When the decision depends on the actual item, the record must stay connected to it.
Presence Layer explores physical verification for objects: linking an item to its identity, origin or custody within a defined process.
What would we evaluate?
The physical property being checked, substitution and tampering, operating conditions, custody gaps and the limits of the resulting evidence.
Evidence before scale
Prove the value
in one workflow.
Start with one action and one accountable owner. Compare the existing process with the proposed check. Measure security, completion time and operational cost together.
Evaluate one workflowWhat a useful evaluation must establish
Agree on the threat model, test conditions and success criteria before testing. Measure verification errors, completion time, user understanding, recovery and the cost of operating the control. Retain failures as well as successful checks.
Use the evidence to decide whether to scale, revise or stop.
See the evaluation approachWhat happens when a check cannot be completed?
Define outages, lost Keys, accessibility needs, alternative routes and escalation before the trial. An exception needs a responsible owner and an explicit policy. It must not silently become the easiest way around the control.
Where the technology stands
Presence Key and Presence Layer are in prototype validation. Workflow integration, compatible readers and performance under the proposed operating conditions must be agreed and validated. The institutional workflows shown here describe the intended direction.
Presence Home is a longer-term direction for coordinating verification across environments.
Understand Presence Key
The longer view
More autonomy.
A clearer human role.
As systems gain the ability to act, the boundary between a suggestion and a consequential decision becomes more important. We study that boundary through physical verification, AI safety and human behaviour.
The aim: checks people understand, evidence institutions can examine, and clear responsibility for what happens next.
Explore our researchWhich action should
still need a person?
Bring us the workflow. We’ll start with the question it needs to answer.
Evaluate one workflow