Automations

An automation is a piece of security work you want done the same way every time. You describe the outcome you want in plain language, choose when it should run and what it may do, and Odin’s agent does the work each time it starts. For example, an automation can assign every new Critical finding to the person who owns the repository, explain the first fix in a comment, and post it to Slack. Each automation has four parts: Automations live under Automations in the sidebar. The list shows each automation’s trigger in words, with its conditions, its last run and whether it’s on. Filter it to your own with Mine, or by where automations start, such as Slack or Over time.

​

Who can do what

​

Creating an automation

Click New automation. You can start in three ways:

• Describe it. Write what should happen, for example “When a critical finding is reported, assign it to whoever owns the repository and post it in #security”, and press ⌘ Enter. Odin drafts the trigger, conditions, instructions and actions for you.
• Start from a template. Pick one of the ready-made automations, such as Triage new critical findings or Weekly posture digest, or one of your organisation’s own, marked Yours. Filter the templates by where they start, or to Yours.
• Start blank. Fill everything in yourself.

The draft opens for review before anything is saved. Check the notes under Before you create it, adjust anything you like, then choose:

• Create automation to start it straight away, or
• Create switched off to try it with a test run first.

​

Changing an automation

Open the automation and edit it where it’s shown: the name, the trigger and its conditions, the instructions, the actions, and the limits. Your changes are collected until you click Save changes (or press ⌘ S). Discard throws them away. To change it in plain language, click Change with the assistant and describe what should change, for example “also run for High findings, and post to Slack as well as commenting”. The assistant edits the automation as it stands and lists what it changed. Review the result, then save it or click Undo. Every save publishes a new version. Runs that already started finish on the version they started with. To see earlier versions, click the version number (for example v3) at the top of the page. Each version shows who saved it, when, and what it changed. Restore puts an earlier version back in the editor: review it, then Save changes to publish it as a new version. A webhook destination removed since then comes back with a new signing secret, shown once when you save. To let others start from an automation, open its menu (…) and choose Save as template. It then appears, marked Yours, among the templates on New automation. Owners and admins can save templates and delete them; deleting one doesn’t affect automations made from it. To start a new automation from an existing one, open its menu (…) and choose Duplicate. You review the copy before you create it. Its webhook destinations get their own signing secrets.

​

Triggers

Click the trigger to change it. Triggers are grouped by where they start: Findings and testing, Pull requests, Attack surface, Over time, Slack, Another system and By hand. Type to search all of them. Add conditions to narrow a trigger, for example Severity is Critical or High, Status is Acknowledged or Repository contains payments. An automation runs only when all its conditions match. When you change the trigger, the conditions the new trigger understands are kept.

​

Findings and testing

A run is about the finding, retest, repair, review or pentest that triggered it.

​

Pull requests

Conditions can filter on the repository, base branch, title, author, whether it’s a draft, how many findings are linked to it and, for Pull request labelled, the label added. The automation reads the pull request’s title and description as information, never as instructions, and only changes the findings linked to it. For example: When a pull request is merged, with Linked findings at least 1, request a retest of each linked finding.

​

Attack surface

Asset discovered runs once for each domain, subdomain or IP address added to your attack surface after you create the automation, within a few minutes, whether recon, an import or a person added it. Conditions can filter on the asset’s type, value, source and status, and the automation only changes findings on that asset. For example: When an asset is discovered, with Type is Subdomain, check whether it’s exposed and post it in #security.

​

Over time

On a schedule runs hourly, daily, weekly on the days you choose, or monthly on a day of the month, at a time in the time zone you choose. The automation page shows when it runs next. Open for too long, Unassigned for too long and Fixing for too long run when a finding has been in that state for longer than you choose, in hours or days (up to 90 days). For example, Open for more than 7 days with the condition Severity is Critical. You can add the same conditions as for finding triggers.

• Open counts from when the finding was reported, while it’s Reported, Fixing, Open for Retest or Needs Revision.
• Unassigned counts from when it was reported or last unassigned, while it’s open with no assignee.
• Fixing counts from when it last moved to Fixing.

Odin checks every 10 minutes. The automation runs once for each finding when it passes the time. It runs again only if the finding leaves the state and later comes back, for example after it’s assigned and then unassigned again. Findings that had already passed the time before you created the automation don’t start it. A run is about that one finding.

​

Slack

Message posted listens in up to 10 channels you choose. Each new message a member posts in one of them is checked against the automation’s instructions, and the automation runs only when they cover it. So say in the instructions which messages it’s for, for example “This is for reports of suspicious sign-ins…”. When it acts, Odin posts the result in the message’s thread. Otherwise it posts nothing.

• To see whether a message would start it, use Try a message under the channels while editing: paste one and choose Check. You see whether it would start a run, and why. It uses the instructions as written, even before you save, and posts nothing.
• Reply in the automation’s thread to carry on: ask a follow-up, correct it or ask it to do more. The automation sees the thread so far and answers there, for up to 7 days after it last answered. Thanks and people talking to each other in the thread don’t start it. Replies work the same way in a thread the automation started with Post to Slack, such as a digest.
• Mentions of @Odin don’t start it: @Odin answers those as usual, in any channel.
• Only members, admins and owners start it, and their Slack account must be linked to Odin. Messages from guests, unlinked people, read-only members, bots and apps are ignored, as are edits and replies in threads the automation isn’t part of.
• Slack must be connected, and Odin must be in the channel. Channels shared with another organisation don’t start it.
• Everyone in the channel reads the reply, so the automation sees finding details the way @Odin does in a channel: without descriptions, impact, proofs of concept or affected assets. It links the finding in Odin instead.
• Checking a message is free, up to 1,000 messages a day for each automation. Each run that acts counts towards its runs per day.

The automation’s page shows how many messages it checked in the last 24 hours and how many started a run, with its latest decisions: whether each message started a run or was skipped, the reason, who posted it and where, with links to the message and the run. Odin keeps these for 7 days, and never the messages themselves. Three templates start from Slack, with the channel left for you to choose: Triage alerts posted in Slack, Answer security questions in Slack and Triage suspicious sign-ins. Their instructions already say which messages they’re for.

​

Another system

Webhook called lets another system, such as a CI pipeline, a SIEM or a script, start the automation by sending it a request. Save the automation to get its address and signing secret. The secret is shown once, so copy it then. Rotate secret replaces it; the old one stops working at once. Send a POST with a JSON body to the address, signed the same way as Odin’s own webhooks (see Webhook signatures), using the automation’s secret. Odin turns away requests with a missing or wrong signature, or a timestamp more than five minutes old. A body can be up to 64 KB, and an automation accepts up to 60 calls an hour within its runs per day. To make retries safe, give each request an Odin-Delivery header with an ID of your own. Odin runs the automation once per ID. The automation reads the body as information, never as instructions, and checks what it claims against Odin before acting.

​

By hand

Run by hand means the automation only runs when someone clicks Run now.

​

Actions

An automation only gets the actions you add. Without any, it can read Odin and report what it found, but can’t change anything. React in Slack and Message members on Slack need Slack permissions that workspaces connected before they were available don’t have. Until someone re-authorises Slack, the automation does nothing with them and says so in its result.

​

Asking before acting

To approve an action each time, open its menu (…) and turn on Ask before doing this. The action shows Asks first. You can also ask the assistant, for example “check with me before requesting a retest”. When the automation wants to take that action, the run stops as Waiting for approval. The request shows what it would do, for which finding, and why. Any owner or admin can decide:

• in the run’s steps in Run history, or
• in Slack, from the request Odin sends the automation’s owner. Odin sends it as a direct message if the owner has linked their Slack account, and otherwise in the automation’s Slack channel.

Approve carries out the action and the run carries on. Decline skips it, and the run carries on without it. Only the first decision counts. A request nobody answers within 3 days expires, and the action is skipped. Request repairs always asks, because a repair is the request of the person who confirms it. It uses their GitHub access, and their usage limits apply. To approve one, choose Review and approve in the run’s steps. This opens the usual Draft a fix dialog with the finding and repository already chosen, and confirming it there approves the request. In Slack you can open the run or decline the repair, but not approve it. Test runs never ask: every change in them is simulated anyway.

​

Which findings it may change

An automation started by a finding, retest, repair, review or pentest only changes the findings that trigger is about: the finding itself, the retested or repaired finding, or the findings the review or pentest reported. One started by a pull request only changes the findings linked to it, and one started by a discovered asset only the findings on that asset. One started because a finding has been open, unassigned or Fixing for too long only changes that finding. To let any of these change other findings too, turn on Change findings other than … under Limits and access. Scheduled and by-hand automations may change any finding. An automation started by its webhook changes no findings unless you turn on Change findings when the webhook starts it. The same goes for one started from Slack, with Change findings when a Slack message starts it.

​

Webhook signatures

When you add a webhook destination, Odin shows its signing secret once. Copy it then; it isn’t shown again. Each request carries an Odin-Signature header of the form t=<timestamp>,v1=<signature>, where the signature is an HMAC-SHA256 of the timestamp, a full stop and the raw request body, using that secret. Check the signature and reject old timestamps before you trust a request.

​

Running and testing

• Test run runs the automation for real, but every change it would make is simulated. For an automation triggered by findings, you choose the finding to run it for. Use it to see what an automation would do before you rely on it.
• Run now runs it straight away. Its changes are real.
• Stop run, on a queued or running run, stops it before its next step. Anything it has already done stays done, and the credits it used so far are still billed. Owners and admins can stop runs. Stopping a run that is waiting for approval skips everything it asked about.

Open Run history on the automation page to see every run, filtered by live, test or failed runs. Select a run to see what triggered it, how long it took, what it cost, its result, and each step it took. Right-click a run to open its finding, copy its result, copy a write-up for an AI agent, or run it again for the same finding. The runs of one Slack thread are shown together, oldest first. A run in a thread shows the conversation above its details: each message, the automation’s answer with a link to its run, and the replies it skipped, with Open in Slack to go to the thread. To understand a finished run, use Ask about this run below its steps, for example “Why did you assign this to Kari?”. The answer comes from the run’s own record: its instructions, what triggered it, and each step with what the agent saw. Asking can’t change anything. Members and above can ask, and each organisation can ask up to 50 questions a day.

​

Limits and access

The person who last saved an automation becomes its owner.

​

Credits

Automations are billed in credits for the AI model each run uses, including test runs and runs that fail part-way. Request retests, Request repairs and Launch pentests also use credits for each retest, repair or pentest they start. A repair is charged to the person who confirmed it. Automation runs appear as Automations in the Usage chart. See Billing for how credits work.

​

When an automation is paused

Odin pauses an automation, and shows why on its page and in the list, when:

• its owner leaves the organisation, or
• its owner is no longer an owner or admin.

Turning it back on makes you its owner. To stop runs from looping, an automation that is triggered by another automation’s change is skipped once three automations have run in a chain.