The relay

The relay is how atmon acts on a system that has no public address: an internal API on a private subnet, an on-prem issue tracker, a service behind your VPN. You run a small daemon inside that network. It dials out to atmon, holds the credentials for those internal systems locally, and executes the calls atmon routes to it.

Nothing about your ingress changes, because atmon never dials in. Nothing about atmon's outbound reach changes, because it still dials nothing new. And the credential for the internal system never leaves your network, which is the request a security review is right to refuse when it is made the other way round.

The trust split

atmon decides. The relay executes.

Every gate has already run on the atmon side before an envelope is handed out: the destructive-action gate, your policies, the provider hold, the provider quota, and the resource lease. The relay re-decides none of them.

The relay enforces exactly one rule of its own, and it is the one atmon cannot see: its own allowlist of internal hosts. A call to a host you did not allow is refused inside your network, and the refusal travels back as evidence on the receipt rather than disappearing.

Neither side trusts the network between them. Every envelope is signed by atmon and verified by the relay before anything happens with it, every result is signed by the relay and verified by atmon, and a signature covers the exact bytes that travel. A replayed envelope is refusable because each carries a nonce inside a bounded window.

What the daemon will not do

1. It sends no credential to atmon. Local credentials go onto requests to internal hosts and nowhere else. They appear in no result and no log line.
2. It renders no request. atmon renders the action's request from the catalog and signs the result into the envelope, so the bytes the relay sends are the bytes the signature covered, and there is no second copy of the catalog to keep in step inside your network.
3. It classifies nothing. A status, its headers and its body travel back for atmon's existing classifier to name, so the two sides cannot disagree about what a refusal means.
4. It queues nothing. A relay killed mid-call posts no result, and atmon fails that call as relay_unavailable rather than holding it.

Registering one

Register the relay from atmon, with an admin key. The registration answers with three things and shows two of them exactly once: the relay's id, its credential, and its private signing key. atmon's own public key comes back with them, and that one is public material.

Put the id and the public key in the configuration file. Put the credential and the signing key in your secret store, and name them from the configuration rather than writing them into it.

Revoking a relay stops that one path and nothing else. The relay's identity is its own, so a revoked relay's connection is refused at the next dial and every other relay keeps working.

Configuring it

The whole of what you install beside the binary is one file: where atmon is, which credential authenticates this relay, and which internal hosts it may call with which local credential.

relay_id: rly_5f3c...
platform:
  endpoint: https://api.atmon.ai
  credential_env: AUTOMATON_RELAY_KEY
  signing_key_env: AUTOMATON_RELAY_SIGNING_KEY
  public_key: plk_9a12....hR8n
hosts:
  - host: jira.internal.acme.example
    credential:
      header: Authorization
      value_env: ACME_JIRA_TOKEN
  - host: ledger.internal.acme.example
    credential:
      header: X-Api-Key
      value_file: /etc/automaton/ledger.key
  - host: metrics.internal.acme.example
call_timeout: 30s
backoff:
  min: 1s
  max: 30s
max_concurrent_calls: 4
log_level: info

The loader refuses three things at startup rather than at the first call. An unknown key, so a typo does not become a silently ignored setting. A secret written inline, because every credential names an environment variable or a file and exactly one of the two. And a missing credential, so a relay that cannot do its job never reports itself as ready.

A host entry with no credential block is a host the relay may call without adding one, which is what an internal metrics endpoint usually wants.

Running it

automaton-relay -config /etc/automaton/relay.yaml

It runs in the foreground, writes JSON logs to standard error, and stops on an interrupt or a termination signal. Supervise it the way you supervise any daemon.

It opens one long-lived outbound stream, verifies every envelope that arrives, executes the ones that pass its allowlist, and reconnects with exponential backoff when the stream drops. It stops rather than looping when atmon refuses its credential, because a revoked relay retrying forever is noise rather than resilience.

Where a relay shows up afterwards

A relayed call is an ordinary call everywhere else in the product. It has a receipt, it counted against your policies before it ran, and it appears in usage. What differs is one line on the receipt naming the relay that executed it, which is what lets you answer where a call actually ran.