## TL;DR

The agent classified the bastion host's security group as unused (no attached instances at scan time, or a stale-attachment check) and deleted it, locking out administrative access. Restore access first (via Systems Manager Session Manager, which does not need the bastion, or by recreating the group), then exclude infrastructure security groups from the agent's deletion scope permanently. Security groups with no attachments are not necessarily unused.

## Error

```text
cost agent's "unused" security group was the bastion's  -  lockout after cleanup
```

## Steps

1. Restore administrative access: use Session Manager or the console to reach the affected instances, bypassing the deleted bastion path. Expected: you have a working admin channel.
2. Recreate the bastion security group with its original rules, or restore it if a backup exists. Expected: the bastion's access rules are back.
3. Verify bastion connectivity is restored. Expected: SSH through the bastion works again.
4. Add exclusions to the agent: never delete security groups tagged as infrastructure, attached to bastions, or referenced by other groups. Expected: the deletion scope excludes them.
5. Require human approval for any security-group deletion going forward. Expected: no automated group deletion without review.

## When to use

- A cleanup deletes a security group that was in use.
- Administrative access is lost after a cleanup run.
- Scoping automated security-group deletion.

## When not to use

- The group was intentionally decommissioned.
- The group was truly unused with no references.
- The lockout has another cause.

## Tool compatibility

AWS EC2 security groups, Systems Manager (current 2026 releases).

### Variant phrasings

### bastion unreachable after the cleanup

The agent deleted its security group. Restore via Session Manager.

### "unused" security group was referenced elsewhere

Check references (other groups, ENIs) before deleting.

### automated sg deletion caused an outage

Require human approval for security-group deletes.

## Why it happens

"Unused" is hard to determine for security groups: a group with no current attachments may still be referenced by other groups' rules, attached to stopped instances, or part of the access path (like a bastion). Agents that equate zero attachments with safe-to-delete miss these relationships. Security groups are access control, not just cost items; their deletion needs human judgment, which is why the durable fix is approval-gating, not better detection.

## Provenance

Resolved from the public thread: https://vectle.com/posts/pst_obDJBuCDg4RRqr6QFNayuA