Skip to content

Data access and security

Lazurio’s security model starts with a deliberately limited claim: an agent cannot be made safe by prompt wording alone. Security comes from the identity, machine, repository permissions, scoped tools, secret custody and publication controls around the session. The public collaboration model defines the intended boundary; a concrete deployment still needs verification.

The task agent operates for the signed-in principal. It must not acquire rights merely because a prompt asks it to. Effective access is supplied by the principal’s device sessions, repository grants and provider credentials. This means offboarding and access review must include those underlying systems.

An Organization is the company-level data and access boundary. Separate organizations remain separate repositories and GitHub organizations. Public patterns can move between them; secrets, client data, business strategy and private overlays cannot.

Personalspace is private to one principal and is not a shared company data store. Its privacy boundary has priority over convenience. Company knowledge needed by colleagues belongs in an authorized Organization store, not in someone else’s private context.

The integration standard prefers a locally curated official MCP server, then an official CLI, then a reviewed and pinned open-source implementation. Browser interaction is a fallback. Each machine uses a separately revocable login, and the deployment’s catalogue should contain names and required scopes—not secret values.

The secret custody standard keeps real credentials out of Git. Local ignored paths are scoped by owner or Organization, and tracked source contains only schemas, variable names and instructions. Your endpoint and backup controls must protect the actual local custody location.

ThreatIntended controlAcceptance test
Prompt requests data from another companyOrganization isolation and scoped contextAttempt access with no grant and confirm denial and useful audit evidence.
Agent attempts a protected publicationGitHub/provider permissions plus explicit principal approvalAttempt merge/deploy without required permission or review.
Credential is copied into sourceIgnored custody paths, public-safety scanning and reviewSeed a safe canary matching a token pattern and confirm the pipeline fails.
Integration has excessive accessProvider-side scopes and separate revocationRead live OAuth/app grants and revoke one without affecting unrelated access.
Local machine is lostDevice controls, encryption, credential revocation and recovery procedureRun the organization’s offboarding or lost-device exercise.
Generated explanation drifts from behaviorExact public source links, review dates and CI validationChange or expire an evidence reference and confirm the documentation build fails.

Lazurio can be used through different execution clients and model providers. This documentation does not make one universal data-retention or training claim for all of them. The operator must disclose the selected provider, account tier, region where relevant, enabled telemetry, retention terms and any zero-data-retention arrangement. Treat those provider terms as part of the deployment—not as an inherited property of Lazurio.

Git history, pull requests, exact-head approvals and deployment records provide strong evidence for source changes. They do not automatically cover every model request, local file read or third-party API call. Build an audit map that states which system records identity, action, target, result and retention for each enabled surface.

An authorized identity can still expose information, approve a harmful change, or grant a tool too much access. A process boundary can be misapplied. A model can generate incorrect content. A local endpoint can be compromised. Lazurio’s value is to make these decisions narrower and more inspectable; it does not remove the need for least privilege, endpoint security, provider review, testing and human accountability.