Security model

This page explains the trust boundaries passo.build uses when the console, coding-agent flow, MCP server, repositories, and cloud providers work together.

Core boundaries

Boundary	Rule
User	Actions must be tied to the authenticated human who owns the decision.
Tenant	Data for one organization must not be readable or writable by another organization.
Project	Evidence, locks, assessments, and deploy choices belong to one project unless explicitly linked.
Repository	The agent scans only approved local roots or selected repositories.
Cloud account	Cloud mutations require explicit approval and account-mode clarity.
Secrets	Secrets stay server-side or in an approved secret store; they are not committed, pasted into docs, or sent as local-scan payload content.

Console authentication

The web console uses the passo.build authentication flow. Console actions create project state, evidence, and deploy decisions under the signed-in user.

Admin surfaces are separate from normal user login. Public access should expose only the login paths required by passo.build users; admin consoles, vaults, and operator tools belong behind company-controlled access such as VPN and explicit admin authorization.

Coding-agent authentication

The target agent-native flow is local login:

1. the agent starts login;
2. the user authenticates in a browser or device-code style flow;
3. the MCP session is bound to user, tenant, and project;
4. session material is stored outside the app repository;
5. sensitive operations still require explicit human confirmation.

During rollout, a provisioned bearer token can protect the MCP transport for an agent host. Treat that token as an implementation bridge, not the final user experience.

Local scan privacy

In the agent-native flow, the coding agent reads the repository locally and sends a structured assessment. The payload should contain product and code signals, not a raw source-code archive.

Allowed examples:

• detected frameworks and runtimes;
• package and manifest names;
• presence of API routes, database clients, upload code, auth code, jobs;
• human product answers;
• missing backend/security/deploy signals.

Avoid sending:

• API keys, tokens, passwords, cookies, SSH keys;
• raw customer data or private logs;
• full source files unless the user explicitly approves a diagnostic workflow;
• local absolute paths that reveal private machine details.

Tenant and row isolation

All project records should be scoped by tenant and project:

• assessments;
• answers;
• generated tasks;
• locks and leases;
• evidence;
• deploy approvals;
• audit events.

Application-layer checks are useful but not enough for multi-user operation. The database layer should also enforce tenant/project boundaries for shared tables. Until those controls are verified for a surface, treat that surface as limited to single-operator or controlled beta usage.

Approval gates

These operations always require explicit human approval:

• production deploy;
• Terraform apply or destroy;
• cloud account binding;
• SSO realm/client changes;
• billing or payment settings;
• secret reads or token rotation;
• accepting critical or high security risk.

The agent may prepare the command, evidence, and rollback plan. It must not infer approval from silence.

Evidence, audit, and retention

Evidence should be append-only enough to explain why a decision was made:

• who or what submitted it;
• which project and repository it applies to;
• command or job id when relevant;
• sanitized logs or screenshots;
• timestamp and status;
• controller decision.

Sensitive values must be redacted before evidence is stored or shown to another agent.

Revocation and recovery

If an agent token, local session, or project binding is wrong:

1. revoke or rotate the credential;
2. stop the affected agent task;
3. release or expire stale locks;
4. record the incident in evidence;
5. resume only after the project/session mapping is correct.

Live vs target controls

Control	Status
Web console user login	Live path for normal users.
MCP endpoint on mcp.passo.build	Rollout path; verify with health and tools/list.
Agent local login/session binding	Target user experience; may be host-dependent during rollout.
Provisioned bearer token	Technical bridge during rollout.
Tenant/project segregation for mesh multi-user work	Required before broad multi-user mesh usage.
Admin-only SSO/Vault access behind VPN	Security target; not a public user path.