Credential Injection

Credentials are encrypted at rest (AES-256-GCM) and injected transparently into HTTP requests. The agent never sees the real values.

Built-in services

The credential() helper handles domain, header, prefix, and env var for common APIs:

import { credential } from "@runplex/sylo";

credentials: [
  credential("anthropic", process.env.ANTHROPIC_API_KEY!),
  credential("openai", process.env.OPENAI_API_KEY!),
  credential("github", process.env.GITHUB_TOKEN!),
]

12 built-in services: anthropic, openai, github, stripe, linear, slack, huggingface, cohere, replicate, groq, mistral, fireworks.

Python:

from sylo import credential

credentials=[
    credential("anthropic", os.environ["ANTHROPIC_API_KEY"]),
]

Custom APIs

For APIs not in the registry, use the full credential config:

credentials: [
  {
    name: "custom-api",
    domain: "api.example.com",
    header: "Authorization",
    value: "Bearer sk-proj-...",
    envVar: "CUSTOM_API_KEY",
  },
]

When the agent calls api.example.com, Sylo sets Authorization: Bearer sk-proj-... on the request.

Named mode

Multiple credentials per domain using name and envVar:

credentials: [
  credential("github", readToken, { name: "github-read", envVar: "GITHUB_READ" }),
  credential("github", writeToken, { name: "github-write", envVar: "GITHUB_WRITE" }),
]

The SDK’s sandboxEnv() maps envVar to sylo_cred:name:

GITHUB_READ=sylo_cred:github-read
GITHUB_WRITE=sylo_cred:github-write

When the agent sets Authorization: sylo_cred:github-read, Sylo replaces it with the real token.

AWS SigV4 credentials

For AWS services (S3, R2, DynamoDB), Sylo computes SigV4 signatures per-request:

credentials: [
  {
    name: "s3",
    domain: "*.s3.amazonaws.com",
    type: "aws-sigv4",
    value: {
      accessKeyId: "AKIA...",
      secretAccessKey: "...",
      region: "us-east-1",
      service: "s3",
    },
  },
]

The agent sends unsigned requests. Sylo computes the signature from the stored credentials and sets Authorization, x-amz-date, and x-amz-content-sha256 headers.

How interception works

Sylo auto-infers which domains to TLS-intercept from your credentials and policy rules. You don’t need to manage a mitm list — just add credentials and Sylo handles the rest.

• Credentialed domains: TLS intercepted, credentials injected, policies enforced
• Policy rule domains: TLS intercepted, policies enforced (no credential injection)
• Passthrough domains: TCP forwarded, no interception at all
• Other domains: default policy applies (allow or deny)

Domains with credentials are implicitly allowed even with default: "deny" — you don’t need explicit allow rules for them. Policy rules only add restrictions (limit methods, paths, or rate limits).

You can still pass mitm explicitly for non-credentialed domains that need interception, but this is rarely needed.