Technical Clarity & Governance

A supported environment is a runtime, IDE, agent, protocol, or operating system surface that Cup’n’String can detect, govern, proxy, or secure through a defined support mode. Support depth varies by environment and is shown through labels such as Native Integration, Active Proxy & Shielding, Auto-Discovered, Compatibility Adapter, and Process & Network Governance.

No. Some environments expose rich integration points, while others are governed through process detection, network policy, MCP proxying, provider/API proxying, or compatibility adapters. Cup’n’String is explicit about support level so teams can understand what is governed.

Native Integration means Cup’n’String has product-specific awareness and richer metadata or lifecycle handling. Auto-Discovered means Cup’n’String detects the environment through observable system signals such as processes, sockets, config files, ports, or installation paths.

Active Proxy & Shielding means Cup’n’String sits in the path of agent activity, MCP tool calls, or model/provider API traffic, allowing it to audit, block, redact, or protect secrets before data leaves the workstation or reaches a tool.

Yes. MCP is a key governance surface for AI agents. Cup’n’String can help route MCP activity through managed controls, apply tool allowlists, restrict filesystem and shell access, shield secrets, and produce audit logs where MCP activity is routed through supported paths.

Cup’n’String is designed to govern AI tools, not simply block them. Teams can run in observe, warn, or enforce modes depending on policy. The goal is to let developers use approved AI workflows while reducing uncontrolled data movement, credential exposure, and unsafe tool execution.

Yes. Cup’n’String is designed to shield sensitive material such as API keys, `.env` files, cloud credentials, package registry tokens, SSH material, and signing credentials from accidental exposure through agents, tools, prompts, or unmanaged network paths.

Yes. Cup’n’String can discover and govern local model endpoints such as Ollama, LM Studio, llama.cpp-compatible servers, and OpenAI-compatible local gateways. Teams can control which agents may connect and whether local endpoints may be exposed remotely.

Yes. Cup’n’String supports OpenAI-compatible, Anthropic-compatible, Gemini-compatible, OpenRouter-compatible, and internal model gateway patterns through compatibility adapters and provider/API proxying.

Depending on policy, Cup’n’String can detect unknown processes, observe outbound traffic, restrict unapproved model endpoints, block access to sensitive local services, and surface the activity for review. Known tools can be assigned richer support profiles.

Cup’n’String focuses on local policy enforcement, traffic attribution, tool governance, and secret shielding. Where content inspection is enabled, it is policy-scoped and designed to protect sensitive data rather than collect source code.

No. Cup’n’String is designed to work across common developer environments, including VS Code, Cursor, JetBrains IDEs, Visual Studio, Claude Desktop, Claude Code, and terminal-based agents.

Start with observe mode to understand current AI and local-service activity. Move high-confidence policies into warn mode, then enforce blocking for unapproved providers, sensitive credential paths, unmanaged MCP servers, or unauthorized local service exposure.

No. Cup’n’String complements endpoint security and DLP by focusing specifically on developer workstations, AI coding agents, MCP/tool activity, local services, containers, Kubernetes, and model-provider egress.

Yes. Cup’n’String can provide visibility into governed AI agent activity, provider access, MCP tool usage, local service exposure, and policy decisions, helping security and platform teams understand how AI development tools are being used.

Developer Preview means the integration is early and may evolve. It is useful for testing coverage and collecting feedback, but teams should validate behavior before relying on it for strict enforcement.

Yes. Cup’n’String includes a dedicated Enterprise Identity plane that federates with major Identity Providers (IdPs) such as Okta, Microsoft Entra ID (Azure AD), Ping Identity, and other SAML 2.0 or OpenID Connect (OIDC) compliant systems. This secures both administrator console access and developer workstation agent enrollment.

Yes. Cup’n’String supports automated user lifecycle management via the SCIM v2 protocol. This allows security and platform teams to automatically synchronize directory groups, map workstation access control policies based on role membership, and immediately revoke agent access during developer offboarding.

Rather than relying on static, shared enrollment tokens that can be leaked or reused, Cup’n’String uses Identity-Aware Enrollment. Workstation agents must be authorized through a secure browser authentication flow (via OIDC/PKCE) tied to a verified enterprise identity before they are allowed to bind and establish policy tunnels.

Yes. For organizations with strict compliance, sovereign data, or high-security requirements, we offer a Standalone Enterprise Edition. This edition is packaged for standard container platforms and runs entirely inside your private cloud or secure on-premises network, keeping all policy logs, cryptographic keys, and database telemetry under your complete control.