Credential Shielding

Prevent AI Agents from Reading Secrets

AI coding agents and MCP tools run with the same local access a developer has — including `.env` files, API keys, and cloud credentials. Cup’n’String is designed to shield that material, route provider traffic through a credential-injecting proxy, and record which agents attempted to reach sensitive paths.

Join the waitlist Supported Environments

Why this matters

On a developer workstation, the most sensitive material is rarely in a database — it sits in plaintext files and environment variables that any local process can read. AI agents expand the number of processes that can read them, often without clear attribution.

`.env` files, API keys, and OAuth tokens stored in project directories

Cloud credentials in `~/.aws`, `~/.config`, and shell profiles

SSH keys, signing keys, and package registry tokens

Secrets pasted into prompts or read by MCP filesystem tools

No central record of which agent or tool accessed which secret

The Cup’n’String approach

Cup’n’String approaches credential exposure as a governance problem: shield the material, broker the access, and attribute every request so security teams have evidence.

Local zero-trust proxy injects provider API keys at the gateway, so workstations avoid storing plaintext provider keys

Policy can restrict tool and agent access to sensitive paths where activity is routed through supported controls

Secrets are held in tenant-isolated encrypted keystores rather than scattered across machines

Outbound activity is attributed to a specific tool, agent, or identity for review

Audit evidence records policy decisions and access attempts

How it works

Step 1Developer workstation
Step 2Cup’n’String Desktop Agent
Step 3Local discovery & classification
Step 4Tenant policy engine
Step 5Credential shielding & enforcement
Step 6Audit trail & admin visibility

Checklist

Can you see which tools attempt to access secrets?
Can you keep provider API keys off developer machines?
Can you apply policy to sensitive file and credential paths?
Can you attribute access attempts to a specific agent or identity?
Can you produce audit evidence for a review?
Can you self-host so secrets never leave your environment?

Frequently asked questions

Does Cup’n’String guarantee an agent can never read a secret?

No tool can make an absolute guarantee on a general-purpose workstation. Cup’n’String is designed to reduce exposure through credential shielding, brokered provider access, policy, and audit — strongest when activity is routed through supported proxy and firewall controls, and paired with operating-system or MDM controls where required.

How are provider API keys protected?

Requests to cloud LLM providers can be proxied locally so the workstation maps a key reference instead of storing the plaintext key. Keys are held in tenant-isolated encrypted keystores and injected at the gateway.

Can policies be applied per user, agent, or device?

Yes. Policy can be scoped by identity, agent, device, and resource, so different roles and machines can have different access to sensitive paths and providers.

Does this work in self-hosted environments?

Yes. Cup’n’String offers a Standalone Enterprise Edition that runs inside your private cloud or on-premises network, keeping policy logs and keystores under your control.

Keep secrets out of reach of unmanaged AI tools

Shield credentials, broker provider access, and capture audit evidence across your developer workstations.

Join the waitlist View Integration Guides

Control MCP Server AccessGovern the tools agents can reach.Audit AI Agent ActionsProduce evidence of agent activity.Cursor AI GovernanceApply this to a specific environment.Supported EnvironmentsSee the full compatibility matrix.Integration GuidesConfigure governance per tool.