Private AGI agent security: local-first by design.

Security here is not one feature. It is a set of layers that each remove a class of risk, and they are easier to trust when they are listed plainly.

The application runs on your machine, and so does the state: the project, the memory, the Task Board and the evidence log. PC LAB does not host your workspace. That is the default rather than a privacy mode you have to remember to enable.

Data moves only when a task needs it to. A cloud model provider receives prompts; a deployment sends files to a server; a browser task touches the web. Each path is a decision, and the agent makes it visible before the action rather than reporting it afterwards.

If you want the whole task on your hardware, run a local model. If you want a provider’s capability, choose one. The architecture keeps that choice open, because a private system that forces a network path is not private in any useful sense.

The network calls that remain are the ones the work genuinely requires: reaching the site you asked it to fix, the server you asked it to check, the provider you chose. A general intelligence that cannot reach the world cannot do the work; the point is that the reach is deliberate.

The default is not a lockdown; it is a starting point. Most tasks need some reach: a folder, a site, a host. The model is to grant exactly that and keep the grant visible, rather than to grant everything and rely on policy documents to constrain it.

That is why the security model is described in terms of what the agent can do rather than what it promises not to do. A capability you have not connected is not a promise; it is an absence of reach.

For a team, the same model scales: each project carries its own connections and permissions, and the audit trail is per project. A shared machine does not mean shared access if the connections are scoped.

The model also survives changes in how the work is done. A new provider, a new connection or a new project does not reset the privacy posture: the same rules apply to the new surface, and the new surface has to be granted before it can be used.

The output belongs to you: the code, the copy, the media, the documents and the reports. It is saved on your machine, in your repositories and in your files. Ownership is not a plan feature here; it is how the product is built.

The output is original work produced for you, not a collage of someone else’s material. Where a task touches third-party assets, such as fonts, plugins, stock media or open-source code, the licence is checked and recorded, and the source forms part of the report rather than being quietly absorbed.

That matters for any business that publishes work. A generated page that carries an unlicensed font, or a code change that copies a licensed library without attribution, creates a liability that outlives the task. The audit trail is what lets you show where everything came from.

The same discipline applies to your own material. Your files, your brand and your data are inputs to the work; they are not training material for anyone else’s model, and they are not pooled with other customers.

For media, the same principle applies to generated assets. Images and video produced by the studio are outputs for your project, created under the model and licence terms you chose, and recorded in the report. They are not scraped from someone else’s page.

Open-source components are treated the same way. Code the agent writes may depend on libraries; the licences are part of the record, and a dependency that cannot be reconciled with your terms is a reason to stop and ask, not a detail to bury.

The practical question for any business is not whether AI will touch third-party material, but whether the touch is recorded. A recorded licence decision is manageable; an unrecorded one is a risk that appears later.

For an organisation, the relevant questions are usually about control, evidence and procurement rather than novelty. The model supports local-first operation, scoped permissions, configurable approvals, an audit trail and model choice, including local inference where the work requires it.

Procurement requirements vary, so the honest approach is to ask about your specific controls. If your organisation needs a security questionnaire completed, a particular deployment arrangement or a data classification mapped to the tool layer, that is a conversation rather than a badge on a page.

The same goes for regulated work. Where the law or a regulator defines who may act, the human keeps the signature and the software keeps the record. That is the arrangement the security model is built for, and it is the one that survives an audit.

The honest summary: security here is not a certificate you display, it is a set of behaviours you can inspect. Read the audit trail of one real run and you will know more about the product’s security than any badge would tell you.

That is also the right way to evaluate the product. Ask for a run on a task that touches data you care about, then read what was logged, what was approved and what was left alone. The answers are more useful than a questionnaire, and they are harder to fake.

Ask for the version number, the connection list and the run log. Those three artefacts tell you more about control than any marketing page, including this one.