How cm-identity-guard Detects Wrong Accounts: The Silent Guardian of Multi-Tenant Vibe Coding

In the high-velocity world of Vibe Coding—where the distance between a raw idea and a production deployment is measured in minutes rather than weeks—the greatest threat isn’t a syntax error or a failing test. It is the Identity Leak.

Imagine this: You are a senior engineer working across three different GitHub organizations. One is your personal playground, one is a stealth startup, and the third is a Fortune 500 client with strict IP policies. You invoke your AI agent to “push the latest auth refactor.” The agent, operating on global credentials or a misconfigured SSH agent, successfully pushes the code. Five minutes later, you realize your client’s proprietary encryption logic is now sitting in your public personal repository.

This is the “Account Collision” problem. In traditional development, a human catches this (usually). In Vibe Coding, where agents operate with delegated authority across multiple cloud providers (Cloudflare, Supabase, Vercel, AWS), the risk of “Wrong Account Action” is catastrophic.

Enter cm-identity-guard. This isn’t just a config checker; it is a multi-layered verification engine designed to ensure that the agent’s Active Identity matches the Project’s Required Identity before a single bit of data leaves the local machine.

The Core Problem: The Identity Ambiguity Trap

AI agents typically inherit the environment of the shell they are running in. Most developers have “dirty” environments:

Global Git Config: A ~/.gitconfig that defaults to a personal email.
Persistent SSH Keys: An SSH agent holding keys for three different accounts.
Cached CLI Tokens: gh, wrangler, and supabase CLIs that stay logged into the last account used, regardless of the folder you are in.

When you tell an agent to “deploy,” it simply runs the command. The command uses the cached token. If that token belongs to the wrong account, the deployment happens anyway—to the wrong destination. cm-identity-guard solves this by treating identity as a locking mechanism rather than a passive configuration.

How it Works: The Four Pillars of Identity Verification

The cm-identity-guard operates through a four-stage protocol that occurs every time a “mutating” tool (like git_push or deploy) is called.

1. The Identity Manifest (`.project-identity.json`)

Every Cody Master project is initialized with a .project-identity.json file. This file acts as the “Source of Truth” for the project’s boundaries. It defines the expected:

Git User: Name and Email.
GitHub Organization/Owner: The specific namespace the repo must belong to.
Provider IDs: Cloudflare Account IDs, Supabase Project Refs, etc.

By hard-coding these requirements into the project structure, we move identity from “Environment-Specific” to “Project-Specific.”

2. Environment Fingerprinting

Before executing a command, the guard fingerprints the current shell environment. It doesn’t just check if a variable exists; it checks for Identity Clashes.

SSH Check: It inspects SSH_AUTH_SOCK and lists the keys currently in the agent. If it finds a “Personal” key in a “Work” project, it raises a flag.
Git Scoping: It runs git config --list --show-origin to see if the identity is being pulled from the global config instead of a local, project-level config.

3. Active Token Validation (The “Who Am I” Gate)

This is the most critical phase. Passive checks (reading files) can be lied to. Active checks cannot. cm-identity-guard executes “identity reflection” commands:

GitHub: gh api user -q ".login"
Cloudflare: wrangler whoami
Supabase: supabase projects list

If the gh api user returns PersonalDev but the manifest requires ClientCorp, the guard hard-kills the process. It prevents the agent from even attempting the push.

4. Session Locking and Continuity

The guard integrates with cm-continuity. When a session starts, the guard “locks” the identity for that specific session ID. If the human tries to manually change a token mid-session, the guard detects the drift in the next turn and refuses to proceed until the session is re-validated.

Practical Example: Stopping a Personal/Work Collision

Let’s look at a real-world scenario. You are working on Cody_Master_Web (the project we see in the sidebar).

The Setup

Current Project: Cody_Master_Web
Target Repo: github.com/todyle-org/cody-master-web
Global Git Config: user.email = "tody_personal@gmail.com"
Current gh Login: tody_personal

The User Request

“Agent, finish the hero section and push it to the main branch.”

The Guard’s Execution Trace

Without the guard, the agent would git add, git commit (using the personal email), and git push (potentially failing if permissions differ, or worse, succeeding if the user has access to both).

With cm-identity-guard:

Intercept: The agent attempts to call git_push.
Manifest Load: Guard reads .project-identity.json. It sees expected_github_org: "todyle-org".
Active Check: Guard runs gh api user. It returns tody_personal.
Comparison: tody_personal does not equal todyle-org.
Environment Check: Guard runs git config user.email. It returns the personal email.
Action: The Guard blocks the tool call and returns an error to the agent:

“IDENTITY CRITICAL: You are currently logged in as ‘tody_personal’. This project requires an identity within the ‘todyle-org’ organization. Action blocked to prevent account contamination.”
Recovery: The agent now knows it cannot proceed. It informs the user:

“I’ve blocked the push because my current GitHub identity (tody_personal) doesn’t match this project’s requirements (todyle-org). Please run gh auth login with your work account, or provide the correct credentials.”

Deep Dive: The Logic of `verify_git_integrity`

For the advanced architects, let’s look at the pseudo-logic used to ensure Git history remains clean and attributed to the correct account.

async function verifyGitIntegrity(manifest: ProjectIdentity) {
  const currentEmail = await run("git config user.email");
  const currentOrigin = await run("git remote get-url origin");

  // 1. Check for Global Contamination
  const isLocalConfig = await run("git config --local user.email").catch(() => false);
  if (!isLocalConfig) {
    throw new IdentityError("Git identity is being pulled from Global config. Use 'git config --local' to lock identity.");
  }

  // 2. Validate Remote vs. Manifest
  if (!currentOrigin.includes(manifest.githubOrg)) {
    throw new IdentityError(`Remote origin ${currentOrigin} does not match expected org ${manifest.githubOrg}`);
  }

  // 3. Prevent "Ghost Commits"
  // If the last commit was made by a different user than the current manifest,
  // we might be about to create a fragmented history.
  const lastCommitAuthor = await run("git log -1 --pretty=format:'%ae'");
  if (lastCommitAuthor !== manifest.expectedEmail) {
    logger.warn("Last commit author does not match current manifest. Proceed with caution.");
  }
}

This level of rigor ensures that the “Vibe” stays professional. In Vibe Coding, your git log is your resume and your audit trail. Fragmented identities (where half the commits are @gmail.com and half are @company.com) are a sign of unmanaged agent usage.

Best Practices & Tips for Identity Management

To get the most out of cm-identity-guard and maintain a safe Vibe Coding environment, follow these advanced patterns:

1. Use SSH Agent Isolation

Instead of one massive SSH agent, use direnv or a similar tool to set SSH_AUTH_SOCK to a project-specific socket. cm-identity-guard can detect if the current socket only contains the keys permitted for the current project.

2. The “One Terminal, One Identity” Rule

Never switch accounts in the same terminal window where an agent is active. Even if the guard catches it, you are introducing “Context Poisoning.” If you need to switch from a personal project to a work project, close the terminal and open a new one. This clears the agent’s short-term memory of the previous account.

3. Commit Signing as a Hard Requirement

In your .project-identity.json, enable require_commit_signing: true. The guard will then verify that not only is the email correct, but the GPG or SSH signature key is available and matches the identity. This provides cryptographic proof that the agent is acting on behalf of the authorized user.

4. Auditor Logs

Check your logs/events.jsonl (as seen in the project structure). cm-identity-guard logs every identity check. If you see a high frequency of “Blocked” attempts, it indicates that your environment switching logic (the human part of the loop) is failing, even if the software is catching the errors.

Why This Matters: The Future of Agentic Security

As we move toward Autonomous Agents that can handle entire PR lifecycles from start to finish, the human will no longer be there to click “Confirm” on every git push. We are entering an era of “Background Engineering.”

In this era, Identity is the new Perimeter. We no longer worry as much about firewalls; we worry about who the agent is claiming to be when it talks to an API.

The cm-identity-guard is the first step toward a Zero-Trust Development Environment. It assumes that the environment is “dirty” by default and that the agent is “naive” by default. By enforcing a strict verification gate, it allows you to “Vibe” with confidence, knowing that your personal life and your professional obligations will never accidentally cross paths in a remote repository.

Conclusion

Vibe Coding is about flow, speed, and creativity. But a single “Wrong Account” push can break that flow forever, leading to legal disputes, security audits, and lost trust. cm-identity-guard serves as the seatbelt for your high-speed coding sessions. It runs silently in the background, checking the fingerprints of your environment against the requirements of your project, and only speaks up when it’s time to save you from a hundred-thousand-dollar mistake.

Lock your identity, verify your tokens, and keep your vibes clean.