A defensive AI agent does the routine work of a security job around the clock. It reads new advisories, checks your inventory, investigates what it cannot confirm, prepares and tests fixes, applies the ones you have approved in advance, and verifies the result. Attackers already use AI to probe systems at any hour, and a defense that only runs during office hours leaves the rest of the day open.
Your team decides what the agent may do before it starts. The connected systems enforce that authority, including permissions, spending limits, and a stop control. When a step falls outside it, the agent hands an accountable person a prepared decision, not a raw alert.
The agent turns one advisory into finished, prepared, and escalated work, so people only see what needs them. All asset names, identifiers, versions, times, and results in this guide are fictional.
Define the job before choosing the tools
Tell the agent which exposure to reduce and what finished looks like. It turns that direction into a job brief. It reads your inventory, existing policies, and recent advisories to propose the asset scope, sources, and actions, and then you approve or adjust the draft. Scanners, inventories, and scheduled checks keep supplying facts. The agent connects that evidence, investigates gaps, and carries the work forward.
Define a focused agent job covers context, actions, and handoff. A defensive brief also needs the asset scope, the actions the agent may take on its own, and the decisions it must bring to a person. Those last two are yours to set; the agent can only propose them.
Start with one of six defensive jobs
Choose one workflow to configure or build. In each, the agent does the investigation and follow-through:
- Patch watching: the agent matches each advisory to your deployments, ranks affected assets, tests the fix, and applies it where policy allows.
- Key rotation: the agent finds every application that uses a credential, stages the replacement, and confirms each one switched over.
- Update checking: the agent compares each new release with its approved source and version and holds anything unexpected.
- Spending watch: the agent investigates usage spikes back to the key, account, and workload responsible.
- Forgotten-system discovery: the agent reconciles repository, deployment, and access records and ranks systems nobody owns.
- Incident triage: the agent gathers logs and alerts into one timeline, drafts the update, and assigns follow-up.
For unapproved tools staff adopted, start with shadow AI governance.
Choose the first job by exposure and usefulness
Ask the agent to survey the candidates first. It can report which reachable systems hold sensitive access, which sources it can read reliably, and how many open findings each job would address. You then weigh what an unresolved exposure would cost the business and which actions you are comfortable approving in advance.
Finding another thousand vulnerabilities is easy to celebrate. Knowing which ten to fix first, fixing them, and proving the fixes held is where the value is. An agent can do all three when the job is bounded and the results can be checked against trusted records. Choose an AI agent use case gives the wider selection method.
Follow an advisory through the workflow
At 02:10, run fic-0210 picks up advisory ADV-FIC-104, which names server component versions 4.2.0 to 4.2.3. The agent checks four approved deployments and works each one to the furthest point its authority allows:
wiki-intis affected but internal only. It falls under the team's pre-approved patch policy, so the agent patches it and verifies the result.portal-prodis affected and customer facing. The agent tests the fix in staging and books it for the owner's approval.billing-apiis unaffected.reports-02cannot be checked. The agent tries a second approved source, then escalates with its diagnosis.
Defensive agent job brief: patch watching (illustrative)
- Exposure: Deployments affected by an emergency advisory.
- Trigger: New advisory from an approved source.
- Asset scope: Approved deployments of the named component.
- Approved sources: Advisory feed, deployment inventory, package manifests, reachability records.
- Tool identity: Dedicated service identity for these reads and actions.
- Actions the agent takes on its own: Match versions, rank assets, test fixes in staging, open and update remediation items, and patch internal systems in the approved maintenance window. After each change, recheck the deployed version.
- Decisions brought to a person: Production changes to customer-facing systems, plus any shutdown, restart, or out-of-window change.
- Enforcement boundary: The deployment system allows patch operations only on hosts tagged
internalduring the window and denies stop and restart operations.- Decision owner: Each asset's platform owner.
- Escalation condition: A lookup that fails on every approved source, conflicting evidence, or a requested change outside policy.
- Done when: Every asset is patched and verified, confirmed unaffected, awaiting a prepared decision, or escalated with a diagnosis.
Action queue from run
fic-0210(illustrative)
wiki-int: Version 4.2.2, checked 02:12. Internal only, so the pre-approved policy applies. The agent patches it in the 02:30 window and reads back version 4.2.4 at 02:41. Exposure: closed, with evidence attached.portal-prod: Version 4.2.1, checked 02:13. Internet reachable, with customer sessions and data at risk: priority 1. The agent applies the vendor fix in staging and passes the regression suite at 02:34. It opensREM-881with the advisory, version, reachability evidence, and test results, and proposes the 06:00 window. Waiting on: portal owner approval.billing-api: Version 4.3.0, checked 02:14, outside the affected range. Unaffected; no action needed.reports-02: The inventory lookup times out twice at 02:15. The agent reads the package manifest from the last deployment record instead, but that record is 40 days old. It marks the asset unverified and escalates to the platform operator with both failures and the stale-record date. Not counted as covered.
At 06:00 the portal owner approves REM-881. The agent deploys the fix, reads back version 4.2.4 at 06:09, reruns the reachability check, and closes the item. The owner reviewed one prepared change instead of investigating four systems overnight.
The agent drafts a brief in this format for each new job, and you approve it. Use the blank version to set what you expect it to fill in:
Defensive agent job brief (blank)
- Exposure: ___
- Trigger: ___
- Asset scope: ___
- Approved sources: ___
- Tool identity: ___
- Actions the agent takes on its own: ___
- Decisions brought to a person: ___
- Enforcement boundary (systems enforcing it): ___
- Decision owner: ___
- Escalation condition: ___
- Done when: ___
Decide what the agent may do
This is the part that stays with people. Give the agent a dedicated identity that can be limited and revoked. Then decide which actions it takes on its own and which it prepares for a person. Write that split into the systems themselves, not only into the agent's instructions. The agent can then run the boundary tests against both sides.
In a boundary test after fic-0210, a reviewer asks the workflow to stop portal-prod using the agent's identity. The deployment system returns a permission denial, and the deployment stays unchanged. The agent records the denial and creates escalation ESC-104 at 02:20 with the request attached. Inventory access beyond the assigned component has not been tested yet, so expansion waits for that test.
The agent writes up each test with intended policy, observed behavior, and untested scope kept separate, following the security review checklist. Use permissions and boundaries and human review to design enforcement and escalation.
Test the result before widening coverage
The fictional run and boundary test produce these results:
Scroll horizontally to see all columns.
| Case | Expected | Observed | Result |
|---|---|---|---|
Affected, pre-approved wiki-int | Patched in window, version verified | 4.2.4 read back at 02:41 | Pass; closed |
Affected, customer-facing portal-prod | Fix tested, prepared change, no unapproved deploy | REM-881 with test results; deployed after approval | Pass; closed at 06:09 |
Unaffected billing-api | Recorded pass with evidence | Version check, 02:14 | Pass |
Unavailable reports-02 | Second source tried, unverified, escalated | Stale record flagged; operator assigned | Pass |
Stop portal-prod | System denial, escalation, no change | Permission denied; ESC-104; unchanged | Pass |
Fail any unsupported verdict, false coverage claim, or production change outside policy. Have the agent compare its results with your existing scanners and checks and report where they overlap and where each one missed something. Evaluate an AI agent separates outcome, process, boundaries, and recovery scores.
For the pilot, let the agent run one brief against a small inventory and spot-check a sample of its verdicts by hand. Then point the agent at legacy systems or trusted software and services.
In AgentShelf
Configure a defensive workflow with approved context and tools, an owner, and limits enforced in connected systems. See the platform overview and trust boundaries, or request agents to discuss a first job.