An agent security program does not need to begin with a comprehensive census or a new committee. It needs an accountable owner, a useful view of where authority exists, and a first control that demonstrably changes an outcome. The first ninety days should establish that operating loop before expanding the tooling footprint.
This plan assumes a small team supporting several AI experiments and at least one production workflow. Adjust the pace to the environment. The phases are acceptance milestones, not a promise that every organization can reach full coverage in a quarter.
Days 1 through 15: define the scope of responsibility
Name the program owner and the people who can change application, identity, cloud, and data permissions. Select one business workflow with meaningful usage and a cooperative service owner. Avoid making the first pilot a dormant demo or the most complicated, business-critical system in the company.
Write down what the workflow does, which data it handles, who initiates tasks, and which external effects it may create. Identify the credentials and tools available to the agent. Record the routes that security can observe and the routes it cannot yet see.
Use read-only sources to start: identity grants, cloud inventory, repository configurations, and existing network or administrative logs. Label each observation with source and time. Do not treat an inferred framework dependency as proof of an active deployment or a connected integration as proof of enforcement.
The deliverable is a short authority map and a named pilot owner. The acceptance check is that the team can trace one legitimate task from initiating user to provider resource, including the account under which the action executes.
Days 16 through 30: define the first enforceable boundary
Choose a consequence worth preventing, such as an unauthorized external export, production mutation, or cross-customer access. Write a rule that identifies the principal, resource, operation, destination, and relevant limits. Keep the rule understandable to the workflow owner.
Place the control where it can mediate the actual effect. A model endpoint change may cover prompts while local tool execution remains separate. A permission hook may cover supported client actions while a direct provider token remains usable. Document these limits and close the most material bypasses before claiming protection.
Establish a safe learning period for ordinary work without relaxing the high-consequence boundary. Observed behavior is evidence about requirements, not automatic permission. Have the owner review proposed standing grants and exceptions before activation.
The deliverable is one active, scoped control with a documented failure behavior. The acceptance check is a permitted task that finishes and a prohibited synthetic action whose downstream effect does not occur.
| Phase | Deliverable | Acceptance evidence |
|---|---|---|
| Discover | Authority map for a real workflow | Source-backed identities and connections |
| Protect | One consequence-based boundary | Permitted task and denied effect |
| Operate | Response and exception procedures | Tabletop and revocation exercise |
| Expand | Second workflow and release gates | Repeated coverage and utility checks |
Days 31 through 45: make the evidence usable
Give every mediated action a correlation path through identity, policy decision, tool call, and provider outcome. Record the policy revision and material resource identifiers. Keep sensitive content out of routine logs unless it is needed and appropriately protected.
Build a small set of views for operators: current authority, recent consequential actions, denied or held requests with reasons, expired or unowned exceptions, and collection or enforcement failures. A large event count is not a substitute for these answers.
Decide how findings become work. Assign owners, due dates, and disposition reasons. Do not automatically declare every unusual request an incident. Escalate according to evidence and consequence, using the organization's existing incident process.
The deliverable is a reviewable record for the pilot. The acceptance check is that an analyst unfamiliar with the implementation can reconstruct one task and distinguish an attempted action, a policy decision, and a confirmed provider effect.
Days 46 through 60: rehearse failure and recovery
Run a tabletop in which the agent attempts an unauthorized action after reading untrusted material. Include a scenario with a configuration error rather than an attacker. Exercise ownership, containment, evidence preservation, and restoration with the service team.
Test disabling the workload and revoking a connection. Measure how quickly fresh calls stop across gateway instances and queued workers. Test policy-service unavailability and a provider timeout after dispatch. Confirm that retries do not duplicate consequential effects.
Review the approval workload. Identify rules generating repetitive, low-value interruptions and propose narrower standing grants where justified. Preserve heightened review for new destinations, privileged changes, sensitive exports, and actions beyond agreed ceilings.
The deliverable is an exercised runbook with named operators and recovery steps. The acceptance check is an observed containment result and a documented account of any path that continued to work after the intended revocation.
Days 61 through 75: introduce release discipline
Create an evaluation corpus from the pilot's real tasks and the failure modes discovered so far. Pair malicious cases with similar legitimate work. Test identity substitution, changed arguments after approval, direct bypasses, cumulative budgets, and stale permissions.
Record versions of the model, prompts, tools, policies, and detector configuration. A change to any of these can affect the outcome. Require a reviewed explanation when security or utility regresses, rather than relying on a single aggregate score.
Set rollout and rollback criteria before changing production. A tenant-boundary failure may block release outright. An increase in low-risk review volume may justify a limited monitored deployment. Make these choices explicit and attributable to the people responsible for the workflow.
Days 76 through 90: expand the pattern, not the claim
Choose a second workflow with a different execution surface. If the pilot used a service agent, consider a coding-agent or SaaS-administration workflow. Reuse identity, policy, evidence, and incident patterns while testing the new enforcement path on its own terms.
Report coverage against a defensible denominator: selected accounts, repositories, identity tenants, and active workloads. Include unknown owners, stale collectors, direct execution paths, and controls that have not yet been verified. A smaller honest coverage figure is more useful than a broad claim nobody can reproduce.
At the end of the quarter, leadership should see concrete outcomes: a source-backed authority map, tested boundaries on real work, a response process that has been exercised, and release checks that preserve both safety and usefulness. The next investment should address the largest evidenced gap, not the longest feature list.