The AI Security Engineer for App Hardening

Security vulnerabilities do not announce themselves. They sit in production for months, sometimes years, an API key in a git commit that was pushed in 2022, a dependency with a known RCE that was never updated because the team had no automated scanner, an IAM role with * permissions that was created during a weekend hackathon and never scoped down. The pattern is consistent across teams of every size: security is treated as a phase that happens after the feature is built, which means it competes with the next feature for sprint capacity and usually loses. By the time the security review happens, if it happens, the cost of fixing what is found has grown by an order of magnitude because the vulnerable code is woven into production systems that other things depend on. The engineering discipline that prevents this is not exotic; it is systematic, applied early, and requires someone who knows what to look for. That is what Warden does.

Why the generalist approach breaks down

Ask ChatGPT to add authentication to a FastAPI service and it will write JWT middleware. What it will not do is notice that the JWT is being validated without checking the alg header, a vulnerability that allows an attacker to sign their own tokens if the server accepts the none algorithm. It will not check whether the secret used for signing is loaded from an environment variable or hardcoded in the configuration file. It will not flag that the user input going into the query is interpolated with an f-string rather than parameterized, which is a SQL injection waiting for a fuzzer to find it. The generalist produces working authentication. It does not produce secure authentication. The difference is invisible until something is exploited.

Cursor and GitHub Copilot have a related limitation: they complete code that looks correct without a security review lens. They will autocomplete a rate-limit middleware block without noting that it is keyed on IP address, which is trivially bypassed with a rotating proxy. They will complete a CORS configuration without checking whether the Access-Control-Allow-Origin: * setting is appropriate for an endpoint that reads user data. They will suggest a dependency without checking whether it has outstanding CVEs. These are the gaps that a security engineer fills, not by writing different code, but by reviewing existing code with the explicit question: how could this be exploited?

The supply chain dimension is where generalist tools fail most completely. A service's attack surface is not just the code you write, it is the code you import. A popular npm package with a typosquat name, a transitive dependency with a critical RCE patched three months ago, a Docker base image that has not been updated since the last kernel vulnerability disclosure, these are the attack vectors that static code review misses entirely. An effective security agent needs to look at the full attack surface: the code, the dependencies, the configuration, and the runtime environment. Warden does.

What a security engineer actually does

On a human engineering team, the security engineer is the person who reviews features before they ship with an adversarial mindset, not trying to make the code work, but trying to make it fail in ways the author did not intend. They run security audits that cover the full attack surface: secrets in code and environment configuration, vulnerable dependencies in the dependency tree, IAM permissions that grant more access than the service actually needs, injection vectors in user-supplied input, authentication logic that has edge cases the author did not consider. They harden services by adding the controls that are missing: rate limiting per user, security headers that prevent the browser from being weaponized against the user, input validation on every user-supplied value before it touches a downstream system.

The security engineer also performs threat modeling before security-sensitive features ship, not after they are in production where the cost of finding a threat is much higher. STRIDE threat modeling (Spoofing, Tampering, Repudiation, Information Disclosure, Denial of Service, Elevation of Privilege) provides a systematic framework for mapping attack surfaces, defining trust boundaries, and identifying mitigations before the code is written. The output is a threat model document that captures the security assumptions the system depends on, the threats that were considered and mitigated, and the residual risk that the team accepts. For any feature that touches authentication, payments, or sensitive user data, that document is the difference between a deliberate security posture and an accidental one. Warden produces it as a standard output.

Meet Warden

Warden is Tonone's security engineer, the specialist agent for full security audits, service hardening, IAM design, and STRIDE threat modeling. Warden's working principle is that security is cheapest when it is applied before the code ships, not after the incident report is filed. Every audit Warden produces is prioritized by actual risk, not by category, a publicly readable bucket with customer data is severity critical; an informational finding about a missing security header on an internal endpoint is low. Every hardening engagement adds the controls that are actually missing, not a generic checklist applied uniformly.

Tonone's Warden runs full security audits across the complete attack surface, secrets, dependencies, IAM, injection vectors, auth logic, and runtime configuration, producing a prioritized finding list with severity ratings and remediation steps.

What Warden actually does

Full security audits across the attack surface

The warden-audit skill is Warden's broadest capability, a comprehensive security audit that covers the full attack surface of a service. Warden checks for secrets in source code and environment configuration (API keys, database credentials, private keys that should be in a secrets manager rather than a .env file), vulnerable dependencies in the dependency tree (using CVE databases to identify packages with known vulnerabilities, including transitive dependencies that the team did not explicitly install), IAM permissions for over-privilege (service accounts with * permissions, roles that grant production access to CI pipelines, humans with admin access to production that should be limited to emergency break-glass), authentication and authorization logic (JWT validation edge cases, missing authorization checks on admin endpoints, session fixation vulnerabilities), injection vulnerabilities (SQL injection via string concatenation, XSS via unescaped user input in HTML templates, command injection in shell-out calls), HTTPS and TLS configuration (HTTP endpoints that should be HTTPS, certificates that are near expiry, cipher suites that include deprecated algorithms), rate limiting (endpoints that can be hammered without throttling), and public storage access (S3 buckets, GCS buckets, or Azure Blob containers that are readable without authentication). The output is a finding-per-item report, each with a severity rating (Critical, High, Medium, Low, Informational), the specific location, and the concrete remediation step.

Hardening services with missing security controls

The warden-harden skill implements security controls on services that are missing them, not a recommendation report, but the actual implementation. Warden adds authentication middleware that validates the token correctly, with alg header checking and key rotation support. It adds input validation on all user-supplied data before it reaches the database or downstream services, using the request schema to define what is acceptable and rejecting everything else with a structured error response. It implements rate limiting per endpoint and per user, keyed on a stable identity (user ID or API key) rather than IP address, with a response that includes Retry-After and X-RateLimit-* headers so clients can handle it gracefully. It adds security headers: Content-Security-Policy configured to block inline scripts, Strict-Transport-Security with includeSubDomains and preload, X-Frame-Options: DENY, X-Content-Type-Options: nosniff, and Referrer-Policy: strict-origin-when-cross-origin. It configures CORS to allow only the specific origins that require access rather than *. And it migrates secrets from environment files and source code into the appropriate secrets manager, AWS Secrets Manager, GCP Secret Manager, or HashiCorp Vault, with the application code updated to read from the secrets manager rather than from a file.

Tonone's Warden warden-harden skill implements auth middleware, input validation, rate limiting with correct keying, security headers, CORS configuration, and secrets migration, the actual controls, not just a recommendation list.

Designing IAM with least-privilege principles

The warden-iam skill designs and implements IAM from scratch using least-privilege principles, the principle that every service account, human actor, and CI pipeline has exactly the permissions it needs for its specific function and no more. Warden defines roles for each service component with the minimum permissions each needs: a read-only reporting service gets read access to the specific tables it reads; a write API gets write access to the tables it writes; a CI pipeline gets access to push Docker images and deploy to staging but not to production. Policies include explicit denies for sensitive actions (creating IAM roles, accessing production secrets from the staging service account) that should never be allowed regardless of what other policies permit. Service accounts are scoped to specific tasks and have short-lived credential rotation. The IAM design is documented with a full access model, which principal can do what to which resource, so the security posture is explicit rather than discovered through an audit. For teams whose IAM grew organically and ended up with over-privileged roles everywhere, warden-iam provides a path from that state to a defensible least-privilege model.

STRIDE threat modeling before features ship

The warden-threat skill runs STRIDE threat modeling for security-sensitive features or system designs before implementation begins. Warden maps the data flows for the feature, identifies the trust boundaries (where is user-supplied data crossing a trust boundary into a privileged system?), defines the threat actors and their capabilities (an authenticated user, an unauthenticated external actor, a compromised service account), and systematically enumerates threats in each STRIDE category: Spoofing (can an attacker impersonate a legitimate principal?), Tampering (can data be modified in transit or at rest?), Repudiation (can a malicious actor deny having performed an action?), Information Disclosure (can sensitive data be read by an unauthorized actor?), Denial of Service (can the feature be used to exhaust resources?), and Elevation of Privilege (can a lower-privilege actor gain higher-privilege access?). For each threat, Warden specifies the mitigation and the residual risk, the risk that remains after the mitigation is in place. The output is a threat model document that the team reviews before implementation, ensuring that security decisions are made explicitly rather than by accident. For any feature involving authentication, payments, or personally identifiable information, the threat model is the difference between a deliberate security posture and one that was discovered through a bug report.

Tonone's Warden warden-threat skill produces STRIDE threat models that identify attack surfaces, enumerate threats per category, and specify mitigations before security-sensitive features are implemented.

Security posture reconnaissance

Before Warden can audit or harden anything effectively, it needs a complete picture of the current security posture. The warden-recon skill performs security reconnaissance: inventorying the secrets management approach (what is in a secrets manager, what is in environment files, what is hardcoded in source code), reviewing IAM policies and their effective permissions (the intersection of what is allowed and what is denied across all policies that apply to each principal), cataloging the authentication methods per service (JWT, OAuth, API key, mTLS), checking encryption at rest and in transit status per resource, running a dependency vulnerability scan and summarizing the results, assessing audit logging coverage (which actions are logged and where, and whether the logs are tamper-evident), and identifying known compliance gaps. The output is a security posture report with risk ranking, a structured summary of the current security state that becomes the input for a targeted hardening or audit engagement. For new projects or inherited codebases, warden-recon is the starting point that ensures Warden's subsequent work is grounded in the actual security state rather than assumptions.

A worked example

A team is about to ship a new payments feature and wants a threat model before the implementation starts. The data flow: a user submits payment details via the frontend, the backend calls Stripe's API, the result is written to the database, and a webhook from Stripe confirms the payment. Warden runs warden-threat and produces the following excerpt:

# warden-threat output, STRIDE threat model: payments feature
# Data flows: browser → API → Stripe → webhook handler → database

assets:
  - name: Stripe API key
    sensitivity: critical  # compromise = full account access
  - name: Payment intent data
    sensitivity: high  # PII + financial
  - name: Webhook endpoint
    sensitivity: high  # unauthenticated by default

trust_boundaries:
  - from: browser
    to: api_server
    notes: User-supplied data crosses here. Validate all inputs.
  - from: stripe_webhook
    to: webhook_handler
    notes: External caller, must validate Stripe-Signature header.

threats:
  - category: Spoofing
    threat: Attacker replays or forges a Stripe webhook to credit a payment
    affected: webhook_handler
    likelihood: high  # Stripe webhooks are publicly reachable
    mitigation: Validate Stripe-Signature HMAC on every webhook request
      before processing. Reject and log any request that fails validation.
    residual_risk: low

  - category: Tampering
    threat: MITM modifies payment amount in transit
    affected: browser → api_server
    likelihood: low  # HTTPS in use
    mitigation: Enforce HSTS with preload. Never accept amount from client
, fetch from server state keyed on payment intent ID.
    residual_risk: very_low

  - category: Information_Disclosure
    threat: Stripe API key leaked via server error response or logging
    affected: api_server
    likelihood: medium  # secrets in logs is a common mistake
    mitigation: Store key in Secrets Manager. Scrub secrets from structured
      log output. Set Stripe key to restricted (charges only, no refunds).
    residual_risk: low

  - category: Elevation_of_Privilege
    threat: Authenticated user triggers payment on behalf of another user
    affected: api_server → database
    likelihood: medium  # IDOR if user_id taken from request body
    mitigation: Always resolve user_id from the authenticated JWT claim,
      never from the request body or query parameter.
    residual_risk: very_low

  - category: Denial_of_Service
    threat: Attacker floods payment endpoint to exhaust Stripe rate limits
    affected: api_server
    likelihood: medium
    mitigation: Rate limit /v1/payments at 10 req/min per authenticated user.
      Return 429 with Retry-After. Log and alert at > 5 req/min.
    residual_risk: low

This is the output a senior security engineer produces before a payments feature ships, not after the first bug report. Each threat is grounded in the actual data flow of the feature, with a concrete mitigation that can be implemented before the first line of business logic is written. The IDOR finding (Elevation of Privilege) is one that generalist tools consistently miss, it requires knowing that resolving the user from the JWT rather than the request body is a security requirement, not just a style preference.

Warden vs the alternatives

Security engineering is one of the domains where the difference between a specialist and a generalist is most consequential. Generalist tools produce secure-looking code; Warden produces code that has been reviewed with an adversarial mindset. The comparison below makes the functional differences concrete.

Install and try

Tonone is free and MIT-licensed. Install it once and all 23 agents, including Warden, are available in your Claude Code session.