Traffic Masking
Traffic masking applies scoped request dictionaries and endpoint-structure rules before supported interlay traffic reaches a backend. Database, cache, service/API, and LLM support depends on the endpoint processor and selected backend profile.
Masking is endpoint governance for request surfaces that are not necessarily AI prompts. It can protect database statements, Redis commands, service operations, document fields, vector/search metadata, and LLM provider-bound JSON bodies where the corresponding processor supports the requested rule shape. Configure it on an Eve interlay through the Interlays API.
Backend Profile Requirement
Full endpoint masking, including SQL, database, cache, and service/API structure masks, requires backend_profile: "development". Production endpoints reject those masking settings. Production endpoints support only LLM and agent request-content PII masking, using request-term configuration that is valid for that endpoint kind.
Use Endpoint Backend Profiles to create a governed development lane when human, agent, or masking-heavy traffic needs inspection away from the production path.
Masking Inputs
| Input | Purpose |
|---|---|
request_terms | Literal case-insensitive terms with allow, audit_only, redact, or block actions. |
rules | Endpoint-family structure masks such as tables, columns, keys, collections, fields, resources, and operations. |
| Scope | global, authenticated_user, auth_group, or endpoint_connection. |
| Endpoint kind | Limit a rule or dictionary to database, cache, service/API, or LLM endpoint kinds. |
Supported Families
| Family | Rule shape |
|---|---|
| SQL-like endpoints | metadata_only, tables, columns |
| Key-value endpoints | metadata_only, keys, commands |
| Document/vector/search endpoints | metadata_only, collections, fields |
| Service/API endpoints | metadata_only, resources, fields, operations |
| LLM endpoints | POST request-body masking for provider-bound model traffic |
The family table describes available processor shapes, not an automatic enablement on every endpoint. Configure a development backend profile before applying non-LLM structure masks.
Example
{
"settings": {
"masking": {
"request_terms": [
{
"scope": "global",
"terms": [
{
"term": "Project Falcon",
"action": "block",
"label": "project"
}
]
}
],
"rules": [
{
"scope": "auth_group",
"auth_group_uuid": "22222222-2222-4222-8222-222222222222",
"endpoint": "postgres",
"rules": {
"metadata_only": true,
"columns": ["patients.ssn", "patients.dob"]
}
}
]
}
}
}Enforcement Notes
- Duplicate terms merge to the strictest action:
Block > Redact > AuditOnly > Allow. - Structure masks run before request dictionary terms.
- SQL, Mongo, and Redis processors reject unsafe rewrites that would change backend semantics.
- LLM POST request surfaces can redact JSON string content before provider forwarding.
- VPN-originated direct gateway traffic can resolve user or agent identity and apply user or auth-group scoped masks.
Scoping Model
| Scope | Use |
|---|---|
global | Apply a dictionary or rule to all matching endpoint traffic in the organization. |
authenticated_user | Apply a rule to one resolved Eden user. |
auth_group | Apply a rule to callers mapped to a configured group. |
endpoint_connection | Apply a rule to traffic using a particular endpoint route or listener. |
Scopes are additive. If the same term or structure is covered by multiple rules, Eden applies the strictest action so a narrow high-risk rule cannot be weakened by a broader allow rule.
Operational Guidance
Use structure masks for known sensitive tables, fields, keys, commands, resources, or operations. Use request terms for business-specific phrases that may appear in free-form requests. For native protocol access through Eve listeners, combine masking with endpoint RBAC, backend profiles, and VPN identity resolution to preserve user attribution.