Jitpass puts Mac developer secrets behind Touch ID for coding agents

Meni Tasa's Jitpass introduces a security layer that moves plaintext developer credentials from files like .env, shell history, and AWS configuration into an encrypted local vault, releasing each value only to approved processes after a Touch ID prompt. The tool, whose public repository showed 587 commits on GitHub as of August 15, 2026, replaces exposed values with decoys or hooks to protect against coding agents that can read files under the developer's account. Jitpass supports credentials for AWS, Terraform, Kubernetes, Docker, Google Cloud, .npmrc, .netrc, and MCP, with wrappers for tools like GitHub CLI, Stripe, Vercel, Claude, Codex, Gemini, and Cursor Agent.

Meni Tasa @menitasa https://x.com/menitasa?ref=runtimewire is building a security layer for the credentials scattered across a developer's Mac: Jitpass https://jitpass.com/?ref=runtimewire , the maker of jit https://github.com/jitpass/jit?ref=runtimewire , finds plaintext secrets, moves them into an encrypted local vault and releases each value only when an approved process needs it. The project attacks an old security weakness that has become harder to ignore as coding agents gain broad access to developers' files and shells. API keys and cloud credentials still sit in .env files, shell history, AWS configuration, .npmrc files and MCP server settings. Any program running under the developer's account can usually read them. An AI agent can also copy those values into a transcript, log or remote model request. Tasa's answer is to remove the real credential from the file without breaking the tool that expects to find it there. Jitpass replaces exposed values with decoys, redactions or hooks, then injects the real secret into an authorized process after a Touch ID prompt. The public repository https://github.com/jitpass/jit?ref=runtimewire showed active development on August 15, 2026, with 587 commits listed on GitHub. Tasa describes himself in his public biography https://medium.com/@menitasa/about?ref=runtimewire as a cybersecurity operations leader with over a decade of experience across networking, IT and security. He also founded the CyberBrief Project, an educational effort covering attacker techniques and practical defenses. That operations background shows in jit's design: the utility is built around the messy places where working developers actually leave credentials, rather than assuming every secret already lives in a centrally managed vault. Replacing files without replacing workflows Jitpass divides the cleanup into three main actions. jit scan searches a user's home directory for exposed credentials without modifying files or printing the secret values. jit migrate moves supported credentials into the vault and rewrites their original locations. jit run -- <command provides selected values to one process while leaving decoys visible to other software. The supported set https://jitpass.com/why-jit?ref=runtimewire includes .env files, shell exports and history, AWS and Terraform credentials, Kubernetes configuration, Docker registry logins, Google Cloud application-default credentials, .npmrc , .netrc and MCP configuration. Jitpass also documents wrappers for command-line tools including GitHub CLI, Stripe, Vercel, Claude, Codex, Gemini and Cursor Agent. Some integrations can request a credential directly. AWS can use its credential process mechanism, while Docker can use a credential helper. Tools that only know how to read a file can run under jit run , which places the required values into that process's environment. Jitpass records successful reads, rejected requests and unlocks in a local audit log. The vault itself stays on the Mac. According to jit's security architecture https://github.com/jitpass/jit/blob/main/docs/security/architecture.md?ref=runtimewire , each secret is stored as an individually encrypted file, with a separate data key wrapped by a master key held in the macOS login Keychain. Touch ID or the device passcode gates access. Jitpass says the vault does not sync and that the product requires no account or telemetry. Coding agents created a sharper endpoint problem Jitpass's most timely use case is the coding agent running with a developer's own permissions. The operating system sees the agent as another local process. If that process opens .env , the file normally returns the production key just as it would for the developer's application. Jitpass's agent design https://jitpass.com/ai?ref=runtimewire changes the contents available at rest. An agent opening the file receives a decoy. When the agent invokes a wrapped command such as gh or terraform , jit can provide the credential to that specific command after approval. The real value can still enter an agent's transcript if the developer explicitly authorizes a process that prints it, a boundary jitpass documents rather than claiming to eliminate. Long-running agents create another problem because nobody is present to answer a biometric prompt after the screen locks. Jitpass supports time-bounded process grants that a developer approves in advance. A command such as jit grant --process claude --profile deploy --for 8h can authorize named secrets for processes descending from a particular terminal session. Each use remains visible in the audit trail, and the grant expires or can be revoked. This endpoint focus puts jitpass beside a much larger push by established secrets vendors. 1Password expanded runtime access https://1password.com/blog/programmatically-read-environments-sdks-desktop?ref=runtimewire for local tools, CI systems and AI-assisted development in February 2026. Its Developer Watchtower https://1password.com/blog/secure-developer-secrets-with-1password?ref=runtimewire can identify plaintext .env credentials and move them into 1Password Environments. The company's Credential Broker https://1password.com/blog/introducing-1password-credential-broker?ref=runtimewire , introduced in June and moved into public preview in July, targets workload identity and scoped credential delivery for systems such as GitHub Actions. Jitpass is pursuing a narrower wedge. It starts with credentials already spread across one developer's Mac and tries to preserve the commands and file formats that created the exposure. Its local vault and process-level prompts reduce the setup and administrative surface, while giving up the shared controls, cross-platform support and organization-wide governance offered by larger products. The security boundary stays deliberately narrow Jitpass does not claim to make a compromised user account safe. Its documentation says a process can do anything it wants with a secret after receiving it. The utility also does not manage every token that another tool creates downstream, including some AWS role and SSO caches. Migrating a credential from shell history is cleanup rather than rotation. Old copies may remain in backups, repositories or the memory of an open shell. Jitpass warns users to rotate those credentials. It also leaves old values in Git history if a secret-bearing file was previously committed. The current build is limited to macOS on Apple Silicon and is still described as under development. Intel Mac users can compile it from source. Although the code is publicly readable, jit uses the PolyForm Perimeter License rather than a conventional permissive open-source license. The repository permits personal and internal company use while retaining tighter control over other commercial uses. That limited scope is also the product's clearest discipline. Tasa is treating the developer laptop as its own secrets-management boundary, with controls built around local files, biometric approval and the process asking for access. AI coding tools have made that boundary busier and harder to inspect. Jitpass is betting that developers will secure it if they can keep typing the same commands afterward.