Skip to main content
Because the Bridger Gateway exposes public data and self-registered APIs under a single domain, the security boundary is its most important responsibility. The following four layers apply to every request.

Authentication

Identify the caller via API Key / OAuth 2.0.

Secret management

Isolate public-data ServiceKeys and BYOAPI tokens in Vault.

PII filter

Mask personal-information patterns in responses.

Audit log

Track who called which tool, and when.

1. Authentication

API Key

The simplest method, used by most users.
curl -X POST https://mcp.datari.kr/mcp \
  -H "x-api-key: $DATA_BRIDGE_API_KEY" \
  -H "Content-Type: application/json" \
  -d '{"jsonrpc":"2.0","id":1,"method":"tools/list"}'
  • Header: x-api-key or Authorization: Bearer <key>
  • Issue/revoke keys at admin.datari.krSettings → API Keys
  • Keys can be revoked instantly whenever needed.

OAuth 2.0

Used when you need organization-level permission management. It supports two flows — Authorization Code and Client Credentials — and the detailed spec is covered in API Reference → Authentication.

2. Secret management

Bridger handles three kinds of secrets.
TypeExampleStorage
Public-data ServiceKeyKey issued by data.go.krVault (Gateway side)
BYOAPI upstream tokenOAuth/HTTP header token for the user’s APIVault, per-tenant isolation
Bridger API KeyCaller authentication key (dk_live_…)DB (hashed) + the token itself is shown once at issuance
Principles
  • Secrets are never included in logs, responses, or MCP metadata.
  • The public-data middleware injects the ServiceKey automatically, so users don’t need to handle the key.
  • On BYOAPI registration, the token a user enters is encrypted and stored in Vault, then immediately removed from memory.

3. PII filter

The following patterns are automatically masked in the response body (including nested JSON).
  • Resident registration number (\d{6}-\d{7}******-*******)
  • Mobile phone number (***-****-****)
  • Credit card number (13–19 digit sequences → ****-****-****-****)
  • Email (***@***.***)

4. Audit log

Every tools/call is recorded with the following fields.
{
  "timestamp": "2026-04-30T07:31:09.412Z",
  "type": "tool_call",
  "action": "tools/call",
  "userId": "usr_...",
  "tenantId": "tnt_...",
  "tool": "getweatherforecast",
  "toolId": "@datari/weather-ultra-shortcast",
  "params": { "...": "masking applied" },
  "status": 200,
  "duration": 312,
  "success": true
}
FieldDescription
timestampISO 8601 record time
userId / tenantIdCaller and tenant identifiers
tool / toolIdCalled tool name and registration ID
paramsInput parameters (stored after masking PII/secret fields)
statusUpstream HTTP status code
durationProcessing time (ms)
successWhether it succeeded
  • Sensitive fields in input parameters are stored after masking, and secrets are never recorded.
  • Secret operations (secret.store, secret.read, secret.rotate, secret.revoke) record only an opaque reference (opaqueRef) separately instead of the value.
  • Search and download via GET /api/v1/audit/logs at admin.datari.krAudit.

5. Network boundary

  • All traffic is TLS 1.3 (wildcard certificate *.datari.kr, cert-manager + Let’s Encrypt).
  • The Gateway defaults to a Kubernetes NetworkPolicy default-deny, reachable only from explicitly allowed ingress sources.
  • Pods use runAsNonRoot + readOnlyRootFilesystem + a least-privilege SecurityContext.

Next steps

API Reference: Auth

Headers, error codes, OAuth flows.

Architecture

Where authentication, middleware, and logging run.