Enclave
Every AI coding tool sends context to a model - the file you are editing, the files around it, the terminal output, the error messages. That context can contain things that should never leave your environment: API keys, database credentials, internal hostnames, PII, proprietary business logic.
The Enclave scans all of it before the request is made. Not after. Before.
What It Does
The Enclave sits between the IDE and any LLM - external or self-hosted. Every piece of context an agent or chat session would send passes through the Enclave first.
If it finds something that should not leave your environment, it acts on it immediately: block the request, redact the content, or log the event. The model never sees the flagged data.
What It Scans
- High-entropy strings - API keys, tokens, private keys, bearer credentials
- Credential patterns - AWS access keys, JWT tokens, database connection strings, OAuth secrets
- PII - email addresses, phone numbers, payment card numbers, national identifiers
- Internal infrastructure - hostnames, IP ranges, service account names
- Custom patterns - regex rules defined by your security team
Every detection is logged with the pattern that matched, the content that was flagged, and what action was taken. The log is in the Console under Observe > Enclave.
Enforcement Modes
You set the policy per detection category:
Block - the request is rejected entirely. Nothing is sent. The developer sees why.
Redact - the detected content is replaced with [REDACTED] before the request is sent. The model gets the rest of the context, minus the sensitive data.
Warn - the request goes through. The developer sees a warning. The event is logged.
Log only - silent logging. No developer notification. Useful for discovery before you commit to a stricter policy.
Sandbox Execution Monitoring
When Power Mode agents run terminal commands, their output feeds back into the agent's context for the next step. A curl call, a secret manager lookup, an environment dump - any of these can produce output that contains credentials.
The Enclave monitors that output too. Anything the agent would read after a command runs passes through the same scan before it becomes context for the next LLM call.
This closes a path that most tools miss: the secret does not arrive in a source file - it arrives in command output, becomes part of the agent's context, and ends up in an LLM request.
BYOLLM
When BYOLLM is configured, requests route to your own model endpoint. The Enclave still runs. Even for models running on your own infrastructure, the scan record exists - every context window that reached the model has a corresponding Enclave event, whether it was blocked, redacted, or passed clean.
For fully on-premises deployments, both the Enclave and the model run inside your network. Nothing leaves.
Custom Detection Rules
Your security team can define additional patterns in the Console or in .inverse/enclave/patterns.json:
{
"patterns": [
{
"id": "internal-service",
"description": "Internal service hostnames",
"pattern": "\\b[a-z]+-service\\.internal\\b",
"action": "redact"
}
]
}Custom rules are evaluated alongside built-in detections. All matches log identically.
Developer Experience
When the Enclave blocks a request, the developer sees a notification in the IDE status bar with what was detected and why. They can view the full event in the Enclave panel. If the detection is a false positive, they can request a policy exception - that request routes to a compliance officer and is logged either way.
Blocked requests are not retried automatically. The developer addresses the issue, then continues.
Available in Enterprise
The Enclave is a Neural Inverse Enterprise feature, available on platform.neuralinverse.com and in on-premises deployments.