Skip to main content

⚙️ How automation works

Not every request for a secret comes from a person. A deployment pipeline needs a database password, a scheduled job needs an API key, a server needs a certificate. Automation lets such a workload use a protected plan without anyone copying a password into it.

It rests on four ideas. You do not need to know how the cryptography works, only what each part is for.

IdeaWhat it isWhere you set it up
ConnectionThe identity of the workload: which GitHub repository and workflow, which Google Cloud service account, which AWS task role, or which runner keyBusiness: Automation connections
PairingThe workload proves it is who the connection says. You open a 10-minute pairing window, and the workload itself sends its proof. No proof is ever copied to you or typed into a chatBusiness, then inside the workload
GrantWhich plan the connection may use, and the responsible member who answers for it. A grant is created, reviewed, then activatedBusiness: the plan's Set up automation
ExecutionThe workload starts its program through the CLI, which fetches the approved fields and gives them only to that programThe workload (see the provider guides below)

Plan rules still apply​

A workload's identity says which machine is asking. It does not say the request is approved. The plan's own rules still run: Organisation Key release, authentication, moderation, the dead man's switch and expiry. A fully unattended run therefore needs a plan whose approvals can be met.

Every use is recorded in the plan's Logs and in the audit trail, including who is responsible for the automation.

Set it up​

You can do the setup in Inheriti® Business, with the CLI or with an assistant through MCP. They do the same thing. In short:

  1. Create the plan that holds what the workload needs.
  2. Prepare the workload: the repository, the service, the task or the runner.
  3. Create the connection in Business, starting as a Test connection.
  4. Pair: open the 10-minute window and run inheriti automations pair redeem inside the workload. It sends its own proof.
  5. Grant access: choose the plan, the connection and the responsible member, review and activate.
  6. Run it and check the plan's Logs.

The in-app guide on the Automation tab of a plan shows each step with the exact values for your provider.

note

The setup is available in Inheriti® Business, in the CLI and through MCP. The in-app guide on a plan's Automation tab shows the exact values for your provider. Test with a Test connection before you use a Live one.

How the workload receives secrets​

The workload runs your program through the CLI:

inheriti secrets exec <plan-id> --automation --env DEPLOY_VALUE=asset.field -- ./deploy.sh
  • Only the fields you map are delivered, and only to that program's environment. Nothing is written to shared environment files or logs.
  • The program's output is hidden by default. You can choose to show it, at the risk of printing a secret into a log.
  • The recipient decides what happens after delivery. Do not send what you receive to logs or to other places.

Stop it again​

To end access, revoke the grant on the plan, or disable the connection. A disabled connection can no longer be used by any job, and the dialog tells you how many plan assignments it affects. See Automation connections.