Security that starts at the machine and reaches the agent.
The base is Furcate, the open operating system from Praecise. What it does is in a public repository, and the platform inherits it.
In short
Security on Praecise Cloud comes from the Furcate base and the platform: hardware-rooted identity, signed updates, an isolated computer per agent, per-project access and secrets kept outside releases. It is for anyone deciding where to run workloads. The claims below stop at what each source states.
00
At a glance.
Open
Read the claims.
Identity, attestation, policy and the kill switch are in the open repository.
Licence
Apache-2.0.
github.com/furcateresearch/furcate.
Live
Praecise runs on it.
Praecise Cloud runs on Furcate.
01
Layer by layer.
- 01
Hardware-rooted identity
A node's name is a key its own hardware made.
No registry issued it and none can revoke it.
- 02
Signed updates
An update replaces an image; it never edits a machine.
A tampered or unsigned update is refused, and a failed component rolls back on its own.
- 03
Authority you hold
Policy is a file you keep.
Deny by default, deny beats allow. Halting, powering down, isolating and erasing a machine are the operator's alone.
- 04
An isolated computer per agent
Agents are kept apart.
Each Silo has its own disk and reaches only the services you connect to it.
- 05
A record of every call
Rules, allowed and refused calls.
Each binding can be narrowed to the tools or paths it may use, and every call is recorded.
- 06
Access per project
Others see only what they are granted.
The Cloud section of Praecise Spaces hides a project from a person who lacks access.
- 07
Secrets outside releases
A rollback carries none.
Environment values are kept beside the site.
- 08
Approvals with attribution
Who approved is recorded.
Harness approvals are attributed and can be signed; a gate needing two people refuses to start without a verifier.
02
Build, Place, Operate, safely.
Build
Guard the tools.
guard.ts decides which tool calls the app makes. Refusals go back to the model as text.
Place
Keep settings aside.
Environment settings are kept outside the folder and the release.
Operate
Limit access.
Grant projects to people in the Cloud section of Praecise Spaces. Revoke a Skerry key to stop an agent paying.
03
Keep a secret out of the release.
Kept
Beside the site.
Environment settings are stored with the site, never inside a release.
Stable
A redeploy keeps them.
A redeploy does not disturb them and a rollback does not carry them.
Source
Set outside the code.
Credentials are set for the project, not committed with the code.
04
The default posture.
Dev server
It authenticates.
It mints a token on startup, binds to loopback, and refuses to start on a visible address without authentication.
Limits
Enforced, not declared.
Budgets count planning and judging, concurrency is bounded, and every model call has a timeout.
05
Questions this answers.
- 01
Can an agent reach the network?
A Silo has no network interface. It reaches only what its owner binds.
- 02
Who can see a project?
Only the people you grant access to a project can see it.
- 03
Can an update be forged?
Furcate refuses unsigned or tampered updates.
- 04
Where are keys held?
Node keys are made by and kept in the machine's own hardware.
- 05
What survives a rollback?
Secrets stay beside the site, not in the release.
- 06
Can I read the claims?
Yes. They are in the public repository.
06
Next pages.
07
Praecise accounts are by invitation. Open the console, or talk to us.
New to Praecise Cloud? Accounts are set up with the Praecise team: talk to us, then sign in to the Cloud section of Praecise Spaces with an email code.