Request policies

Your application sends a placeholder such as secrets://GITHUB_TOKEN. Tenki replaces it with the token only in outgoing HTTPS requests allowed by a policy.

The placeholder always uses the secret's name. The policy has its own name because you can reuse one policy across sandboxes or let it permit several secrets.

You create secrets and policies separately. Each sandbox selects the policies it needs when it starts. Creating a policy alone gives no sandbox access to it.

Create a policy

First save a GitHub token as GITHUB_TOKEN. Then create github-policy.json:

[
  {
    "origin": "https://api.github.com",
    "methods": ["GET"],
    "pathPrefix": "/user",
    "header": "Authorization",
    "secrets": ["GITHUB_TOKEN"]
  }
]

Save it in your workspace:

tenki secrets policies create github --file ./github-policy.json

This permits GITHUB_TOKEN in the Authorization header of GET requests to api.github.com whose path begins with /user. Paths match by prefix, so this also includes paths such as /user/repos.

The JSON file contains permissions, not the token. It is safe to keep with your application configuration.

The policy is now ready to select when starting a sandbox. Policies control secret replacement, not all network traffic. They do not override the sandbox's network restrictions.

Rule fields

A policy is an array of rules. Every rule specifies a destination, permitted methods, a path prefix, a location within the request, and the secrets allowed at that location.

Specify exactly one of header, queryParameter, or jsonPointer per rule. Use separate rules to permit multiple locations.

Putting two names in secrets allows either secret to be referenced. It does not insert both values or choose one automatically. A rule only replaces a placeholder already present in the request; it does not add missing headers or fields.

Query parameters and JSON bodies

For a service that accepts a credential in a query parameter or JSON body, the following policy illustrates both locations. Replace api.example.com with your service's hostname and create the SERVICE_TOKEN secret first.

[
  {
    "origin": "https://api.example.com",
    "methods": ["GET"],
    "pathPrefix": "/v1/",
    "queryParameter": "api_key",
    "secrets": ["SERVICE_TOKEN"]
  },
  {
    "origin": "https://api.example.com",
    "methods": ["POST"],
    "pathPrefix": "/v1/",
    "jsonPointer": "/credentials/token",
    "secrets": ["SERVICE_TOKEN"]
  }
]

Your application can send ?api_key=secrets://SERVICE_TOKEN, or this JSON body with Content-Type: application/json:

{
  "credentials": {
    "token": "secrets://SERVICE_TOKEN"
  }
}

JSON pointers use / to separate object keys or array indexes. Escape a literal ~ as ~0 and a literal / as ~1 in a key. The selected value must be a string.

Use header authentication when your provider supports it. Query strings can appear in the destination's access logs. JSON injection supports uncompressed JSON bodies up to 256 KiB; malformed JSON, duplicate keys, or ambiguous referenced query parameters are rejected.

List and inspect policies

tenki secrets policies list
tenki secrets policies get github

These commands show rules and metadata, never secret values. In the dashboard, use Secrets → Policies.

Edit or delete a policy

Edit the local JSON file, then save the change:

tenki secrets policies update github --file ./github-policy.json

Changes apply to subsequent requests from sandboxes that selected this policy. Editing only the local file has no effect.

To remove that policy's permission:

tenki secrets policies delete github

Another selected policy can still authorize a matching request. In an interactive terminal, policy update and delete commands fetch the current revision. Scripts must supply --revision from secrets policies get.

Deleting and recreating a policy with the same name does not reconnect existing sandboxes to it. Start a new sandbox to select the replacement policy.