Tudovu Assisted Response
In development. Not available in current Garrison or Corps subscriptions.
Investigate suspected threats. Review the evidence and service impact. Approve the exact response.
Pilot scope and pricing discussed with your team
Separately scoped add-on for Garrison or Corps.
From a suspicious signal to an approved action.
The planned workflow keeps investigation, authorization, and execution separate. An alert alone would not authorize containment.
-
Detect a signal
Receive an alert from agreed telemetry for an in-scope AWS workload. Treat it as a signal to investigate, not proof of compromise.
-
Investigate context and uncertainty
Examine the available evidence, workload context, and recent changes. State what is known, what is uncertain, and what needs a person.
-
Propose bounded containment
Describe a playbook action, its exact resource scope, expected service impact, and recovery considerations. Missing context would stop the action from proceeding.
-
Your team approves the exact action
An authorized person reviews the proposal and approves or declines it. Approval would apply only to that action and scope; a changed proposal would need new approval.
-
A restricted executor acts and verifies
Within agreed permissions, the planned executor would perform only the approved action, check the result, and report uncertainty or failure. It would not broaden the action on its own.
-
Record evidence and draft the permanent fix
The evidence timeline and approval trail would be captured as the response ran. The lasting fix would be drafted as a PR for your engineers to review and merge, with documentation updates proposed for approval.
The proposed executor would fail closed: without sufficient context, valid approval, or permission for the exact action, it would stop and surface the issue to your team.
What an investigation could put in front of you.
An unfamiliar outbound connection might indicate compromise. It could also be an expected change. A containment decision needs the evidence and the potential cost to your service.
- Example workload
- Sample background worker in AWS
- Initial assessment
- Potential compromise; not confirmed
- Decision required
- Review a narrowly scoped containment proposal
-
Signal
New outbound activity flagged
Configured telemetry shows an unfamiliar destination for the sample worker. The alert starts an investigation.
-
Context
The explanation is still uncertain
A recent deployment may explain the connection. The investigation asks the workload owner whether it is expected and records the limits of the available evidence.
-
Proposal
Limit one connection, with the service impact visible
If the agreed playbook and resource controls supported it, a proposal could restrict this worker's access to the destination. Background jobs could fail or queue. Shared dependencies and recovery steps would need review before approval.
-
Human decision
Only the reviewed action is authorized
In this fictional scenario, the owner confirms the destination is unexpected. An authorized reviewer accepts the stated service impact and approves that exact restriction. Without approval, no containment action would run.
-
Verification
Check the restriction and workload health
The proposed restricted executor would check whether the approved change took effect and report observed service impact. An inconclusive result would be escalated to your team, not treated as success.
-
Follow-through
Keep the record; review the lasting fix
The evidence timeline would retain the signal, uncertainty, approval, action, and verification result. A permanent configuration fix would return to your normal PR review and deployment gates.
Agree on the playbooks before any action.
Prerequisites to agree together
- Telemetry sources, access, and the evidence available for investigation
- Covered AWS accounts, workloads, and resources
- Scoped executor roles and permitted playbook actions
- Authorized reviewers and approval routing
- Service impact limits, verification criteria, and recovery procedures
Boundaries of the proposed add-on
- Bounded playbooks for agreed resources, not automatic coverage of every threat
- Human approval before each exact containment action; no automatic isolation
- Stop when uncertainty or missing authorization prevents safe execution
- Not a 24/7 staffed response service
- No current response SLA or guarantee of incident prevention or resolution
How this would extend Garrison or Corps.
Today: reviewable PR changes
Garrison and Corps propose infrastructure changes through pull requests. Your engineers review and merge through your deployment gates. Those subscriptions do not currently include Assisted Response or its proposed live containment executor.
Planned: an approved response action
Assisted Response would add a separately scoped path for an exact, human-approved action through a restricted executor. The permanent fix would still go through PR review. Coverage, permissions, and pilot terms would be agreed with your team.
Pilot scope and pricing discussed with your team
Discuss a pilot