Inspiration
An application can be failing even when individual requests look ordinary.
GuardScale was inspired by a production incident where a distributed crawl increased traffic across hundreds of dynamic URLs. Requests resembled normal browser activity and arrived from many IP addresses. Meanwhile, PHP-FPM workers waited on expensive database operations, response times climbed, and the load balancer began returning 504 errors.
Understanding the problem required manually connecting web logs, application behavior, infrastructure metrics, and traffic patterns.
We asked: What if the infrastructure could gather the evidence, investigate further, and contact the operator with a clear next step?
That became GuardScale.
What it does
GuardScale brings server observations, AI-assisted investigation, and human-approved incident response into one workflow.
A Go agent collects bounded observations from a monitored Linux server. The console presents server health, sanitized activity, and incidents grouped by observed source.
When configured, an Amazon Bedrock Guardian inspects actual server evidence before recommending a response. GuardScale then reaches an authorized operator through WhatsApp or email, with incident details and a link to investigate.
The operator remains in control:
- Protect: request a scoped, temporary HTTP(S) source block.
- Watch: continue observation without applying a new block.
- Dismiss: stop further extensions and request removal of active protection.
GuardScale distinguishes a requested action from an agent-confirmed result. An acknowledgement means the response was received; a protection confirmation means the monitored agent reported that the rule was applied.
Why communication is central
Notifications should help resolve an incident, not simply announce another problem.
GuardScale uses AWS End User Messaging Social to send WhatsApp alerts and receive operator replies. Incoming events travel through SNS and SQS to the application worker, where recipient authorization, incident context, and approval freshness are checked.
When exactly one eligible incident is pending, the operator can reply with a simple Protect, Watch, or Dismiss. When several incidents need attention, GuardScale requires an incident-specific code rather than guessing which server to affect.
Amazon SES provides transactional email delivery. Optional signed incident-email replies use the same response policy; their receiving infrastructure is included in the main CloudFormation templates and requires deployment-specific verification.
These are runtime integrations: the application imports and calls the AWS SDK APIs.
Inspect the actual AWS CDS call sites and runtime entry points.
The agentic workflow
Observe → Inspect → Recommend → Notify → Human approval → Act → Verify
The Guardian does more than summarize the initial alert. Its bounded Bedrock workflow first calls inspect_server. The returned server evidence becomes input to the next model step, which requests human review with a recommendation.
The model cannot approve its own recommendation or execute arbitrary shell commands.
If inspection is unavailable or inference fails, GuardScale exposes that limitation and leaves the decision with the operator. A protection request must still pass application authorization and the monitored host's policy checks.
Explore the agent workflow diagram and human-control boundaries.
How we built it
GuardScale combines a Go monitoring agent with a Next.js, React, and TypeScript control plane, plus a separate queue-processing worker.
The AWS architecture includes:
- Amazon Bedrock for bounded inspection and advisory recommendations.
- AWS End User Messaging Social for two-way WhatsApp communication.
- Amazon SES for transactional email and optional incident replies.
- Amazon ECS on AWS Fargate for web, API, and worker services.
- Application Load Balancer for HTTPS application routing.
- Amazon DynamoDB for organization-scoped state, incidents, and commands.
- Amazon S3 for evidence storage.
- Amazon SNS and SQS for messaging events and asynchronous processing.
- AWS Secrets Manager, IAM, and CloudWatch for credential handling, permissions, and operational visibility.
- AWS CloudFormation and GitHub Actions for repeatable builds, versioned artifacts, and reviewed infrastructure updates.
GuardScale supports private installation in an organization's AWS account. Marketplace publication is not required to inspect the source or reproduce the local demonstration.
View the AWS architecture, service choices, and trust boundaries.
Challenges we worked through
The hardest part was connecting a human response to a safe, verifiable action.
We needed to distinguish message delivery from approval, approval from execution, and execution from successful recovery. We also needed to handle duplicate events, ambiguous replies, expired approvals, unavailable inspection, and separate development and production reply queues.
Another important challenge was visibility during protection. Once a request is blocked before reaching Apache, it no longer appears in the application's access log. GuardScale therefore records protection activity separately so the operator can understand why a block remains active.
We added optional bounded renewal when blocked traffic continues, with a finite total duration. Dismiss stops renewal and requests removal rather than merely hiding the incident.
What we tested
Our development demonstration used a real disposable PHP/Apache application, an enrolled Go agent, generated test requests, real Bedrock inspection, and a real WhatsApp alert-and-reply round trip.
We verified an agent-confirmed temporary block and exercised expiry, recovery, and removal behavior. SES outbound delivery was separately confirmed in the authorized recipient's inbox.
The repository includes automated tests for response authorization, protection commands, incident processing, email reply validation, and infrastructure contracts. The local security fixture tests actual blocking inside an isolated container.
These results demonstrate the workflow; they are not a production accuracy benchmark, a fleet-scale load test, or a guarantee that every deployment has all optional integrations enabled. End-to-end SES receiving requires separate live verification.
Review the evaluation evidence, reproduction steps, and limitations.
Responsible operation
GuardScale treats model output as advisory and server evidence as untrusted input.
Protection is opt-in, scoped, and time-limited. The agent enforces local policy and exposes no arbitrary remote shell tool. Observed IP addresses do not establish identity or malicious intent, and shared proxies can affect legitimate users.
The console preserves the distinction between a recommendation, an approval, an applied rule, and its eventual expiry or removal.
Our goal is to help operators make informed decisions with clear evidence and bounded controls.
What we learned
A useful infrastructure agent needs more than a model and a notification API.
It needs trustworthy observations, constrained tools, explicit authorization, understandable failure states, and a way to verify what actually happened. Communication becomes much more valuable when the operator can respond through the same channel and see a confirmed outcome.
Try it and explore the code
- Application: https://guardscale.org
- Source repository: https://github.com/techcto/guardscale
- Judge's field guide and technical report: https://github.com/techcto/guardscale/blob/main/docs/JUDGES_FIELD_GUIDE.md
- Technical setup and testing: https://github.com/techcto/guardscale/blob/main/README-TECHNICAL.md
- AWS architecture and diagrams: https://github.com/techcto/guardscale/blob/main/docs/AWS-ARCHITECTURE.md
- Local incident-response demonstration: https://github.com/techcto/guardscale/blob/main/docs/whatsapp-local-testing.md
GuardScale's first-party code is open source under AGPL-3.0-or-later. The repository includes source, assets, dependency lockfiles, configuration examples, and build and testing instructions.
Log in or sign up for Devpost to join the conversation.