Login and session

An agent connection is not enough by itself. passo.build also needs to know which human, tenant, and project the work belongs to.

That matters because agent actions create evidence, locks, deploy approvals, and eventually cloud changes. Those records must be tied to the right user and project.

Target user flow

The intended agent-native flow is:

1. The agent starts a passo login.
2. You open a browser link or approve a device-code style prompt.
3. passo.build binds the local agent session to your user, tenant, and project.
4. The session is stored outside the repo, under your user profile.
5. Future agent runs resume that session without asking you to log in every time.

The session file must never live inside the app repo. It should be treated like any other local developer credential.

What the session controls

After login, the agent should know:

• which tenant/project it is allowed to work on;
• which repositories are in scope;
• which wizard step is current;
• which tasks are already locked or completed;
• which evidence exists;
• whether a deploy or cloud action needs explicit human confirmation.

If the local repo does not match the active project, the agent should stop and ask before writing evidence to the wrong project.

Current rollout note

The MCP transport can be protected by a provisioned PyxCloud-issued token while the local user-login flow is rolled out. That token is a technical bridge for the agent host; it should not become the user experience and should never be committed to source control.

Session safety checks

Before the agent writes evidence or claims work, it should verify:

• the signed-in user;
• the tenant and project;
• the repository roots in scope;
• the current wizard step;
• active locks and leases;
• whether the requested action needs human approval.

If any of those do not match the local repo or the user's intent, the agent should stop and ask. Writing evidence to the wrong project is a security and audit bug, not a harmless mismatch.