Response actions
What a credential did on someone else's system was, until now, something Trefur could see and not stop. A response action is a policy reaching into a system you have already connected and closing the thing it found: cutting a role's sessions, revoking a person's tokens, or telling you.
These are deliberately narrow. Three action types, a target Trefur reads from the run's own evidence, and a rehearsal mode that is the default until you say otherwise.
The three actions
| Action | What it does |
|---|---|
revoke_aws_session | Denies every session of the role the evidence names that was issued before now — the console's "revoke active sessions", applied as a named inline policy on that role, so re-running it refreshes rather than stacks. |
revoke_github_tokens | Revokes the fine-grained personal access tokens belonging to the login the evidence names, within the connector's organisation, in one call. |
notify_webhook | Sends a signed notification to one of your registered webhook channels. It changes nothing anywhere. |
Rehearsal is the default
A response action is a dry run until its configuration says live. A dry run does everything except the external call: it resolves the target from the run, picks the connector, and applies every refusal below. What it records is what would have happened, so you can leave an action rehearsing for a week and read the outcomes before you arm it.
Set "live": true in the policy definition's action configuration to arm it. Omitting the key, or giving it anything that is not a boolean true, keeps the rehearsal — a typo cannot arm an action.
Where the target comes from
From the run's own steps, never from a request body and never from a policy event's free-form metadata. That is the rule these actions are built on: something that writes to a third-party system must not be steerable by whatever minted the event.
- AWS — the role is read from the run's CloudTrail-attested steps, which is to say from AWS's own signed management-plane records. Trefur takes the last role in the assumed-role chain. A run with no such step is skipped with the reason.
- GitHub — the login and organisation come from the run's GitHub organisation audit-log steps.
Setting a connector up to act
Both AWS and GitHub connectors can be created and armed today, under Inventory → Discovery on the Connectors tab. Acting is never on by default: a connector you already poll with cannot act until you give it something extra.
- AWS — fill in Response role ARN on the connector. That is a second, separate role you create for acting, in addition to the read-only role Trefur polls with. Leave it blank and the connector cannot act, and the verify control does not appear.
- GitHub — create the connector with the organisation and an access token, then tick Allow response actions to revoke tokens.
Either way, the connector then shows a Response actions line with a Verify button. Press it: for AWS this confirms the response role can be assumed, and for GitHub that the credential can list the organisation's tokens — the same call the revocation uses. A GitHub connector must be verified before a policy can act through it. The stamp is cleared by any edit to the connector's configuration or credential, because it attested what was checked, not what you have just replaced.
What has to be true before it runs
- A connector that can act, configured and — for GitHub — verified, as above.
- A server-side detector fired it. A policy runs a response action automatically only from Trefur's own server-side detection. An event minted through the ingest API can name any run in your workspace, and a third-party write must not rest on that.
- The risk gate answered. Response actions fail closed here: if the gate cannot determine the answer, the action does not run. That is the opposite of how the same gate treats Trefur's own internal actions, and it is deliberate.
- It is not your own connector. Trefur refuses to revoke the sessions of a role the connector itself uses. Cutting that would cut the read path and the response path in the same stroke.
Verification is a point-in-time proof, not a standing one. It says the credential worked when it was checked, which is why editing the connector clears it.
What is recorded
The row is written before the external call and settled after it, so an action that crashed mid-flight leaves a pending row rather than no trace.
| Outcome | Means |
|---|---|
pending | Recorded, not yet settled. |
dry_run | Rehearsed. Nothing was called. |
skipped | A refusal above applied, or there was nothing to do — a login with no fine-grained tokens is a success with no call. |
executed | The external call was made and accepted. |
failed | The call was made and did not succeed. |
Each row keeps what was acted on — an ARN, a login, a channel — and who or what triggered it, the policy definition and event, the run and agent, the number of attempts, whether it was a rehearsal, and the error when there was one. The target is identifiers only, never a secret. A settled action also writes an entry to your audit ledger.
When an AWS call is refused, Trefur surfaces AWS's error code and not its message — the message can echo the role name and the calling identity back into your record.
Limits
- AWS covers Bedrock callers. The role is read from CloudTrail-attested Bedrock activity; a run without those steps has no AWS target, whatever else it did.
- GitHub covers fine-grained personal access tokens only. Classic tokens, OAuth-app tokens and GitHub App tokens are outside the API this uses and are recorded as out of scope rather than silently missed. Revocation needs a GitHub App installation with organisation personal-access-token permissions; without it the action is recorded as skipped, with the reason, rather than reported as an outage.
- Response actions are set up by an admin or owner. The Verify control and the response-action fields are shown only to those two roles. Anyone else sees the connector without them.
- Triggering is by policy, not by hand. There is no button in the dashboard, and the one-off trigger endpoint is not exposed on the public API.
- One attempt, no retries. A failed action stays failed and waits for a person; it does not back off and try again.
- Nothing is undone. There is no un-revoke. Restoring access is done in AWS or GitHub.
- Revoking a role's sessions denies sessions issued before the action. It does not delete the role, change its policies, or stop a new session being issued to a principal that is still allowed to assume it.