A backup policy changes on Friday evening. The retention window is shorter than the business requires, but the next backup job still completes successfully. By Monday, the dashboard is green and the protection gap remains.
An AI assistant could help explain the change. An agent connected to the right tools could also correct it. The harder question is what happens next: who checks that the correction worked, keeps watching for recurrence, and preserves evidence of the resulting recovery state?
That is the operating problem behind continuous resilience enforcement. Forttic is built to connect those responsibilities across the existing backup and cloud stack, so a detected gap can move through governed action, verification, and evidence.
Tool access changes what AI can do
It is tempting to frame this discussion as “AI thinks, resilience software acts.” That framing is already too narrow.
Claude is one example. Anthropic documents capabilities for agents to select tools, execute code, and coordinate tool calls. Depending on the implementation and permissions, an agent can do more than summarize a runbook: it can participate in an operational workflow. Anthropic’s tool-use documentation makes that distinction clear.
That capability matters for resilience teams. An agent with suitable integrations could retrieve backup status, investigate a failed job, or invoke an approved action. A custom system could also schedule checks and retain results. The question is how much resilience-specific engineering and operational ownership surrounds those capabilities.
For a backup team, a successful tool call is one event in a longer process. Someone still has to define the required protection state, identify which workloads it applies to, handle exceptions, assess the outcome, and decide when the evidence needs refreshing.
An organization can build that system. It must also maintain it as its cloud estate, vendors, permissions, and recovery requirements change.
MCP connects systems while resilience governance defines the outcome
The Model Context Protocol, or MCP, provides a standard way for AI applications to connect to external data, tools, and workflows. Those connections can enable both information retrieval and actions.
For example, an MCP server could expose a tool that reads a backup configuration or starts a supported operation. The capabilities available depend on what the server exposes and what the connected application is authorized to use.
Resilience governance adds the operational meaning around that interaction. Which policy should this workload follow? Is the proposed change appropriate for its criticality? Does it need approval? What happens if only part of the operation succeeds? What subsequent observation would justify closing the finding?
Those responsibilities belong to the surrounding application and operating process. Adopting MCP does not, by itself, answer them.
This is also why MCP belongs inside the architecture discussion. Forttic’s agentic architecture describes MCP-exposed integrations for existing automation. Connectivity can support an enforcement system, while the system supplies the resilience context and decision boundaries.
A corrected setting still needs a verified outcome
Return to the shortened retention window.
An engineer or agent restores the intended configuration. That addresses the setting, but it may not recover copies that have already expired. The team needs to understand the period of exposure, inspect the recovery points that remain, and establish what can actually be restored.
This illustrative scenario shows why remediation and verification need separate treatment. A configuration change can succeed while a recovery limitation remains. If the finding is closed as soon as the update API returns success, the record can overstate the outcome. How to bound a specific write, including approval and failure behavior, is covered in Before an AI Agent Changes Your Backups.
The same reasoning applies when a disabled job is re-enabled. The change may be necessary, but the next execution and subsequent recovery checks provide different evidence. A useful operating record distinguishes what was requested, what changed, what was tested, and what remains unresolved.
As the environment evolves, that record also needs a clear scope and timestamp. Yesterday’s successful test remains useful evidence about yesterday’s tested conditions. Teams need a way to recognize when a later change affects its relevance.
Forttic’s ResOps enforcement model addresses this continuing relationship between required state, observed drift, corrective action, and recovery assurance. The same distinction — job success versus recovery proof — is why recovery proof is replacing backup job reports as the evidence standard.
How Forttic connects the enforcement loop
Forttic’s CRE framework organizes the work into five stages:
Discover → Assess → Enforce → Verify → Report
Discovery establishes the assets and protection relationships in scope. Assessment compares their observed state with policy and business priorities. Enforcement applies remediation within defined guardrails, with human approval for high-impact actions.
Verification then checks the result. Forttic describes tiered verification, including isolated restores for tier-1 workloads and measurement of recovery objectives. Reporting preserves the findings, actions, and verification records as evidence.
The stages serve different purposes. A complete inventory cannot demonstrate that a restore succeeded. An approved change cannot establish that all affected controls now meet policy. A report is useful only to the extent that the underlying observations support its claims.
Keeping these stages connected helps teams follow a finding through to an evidenced outcome. It also makes unresolved gaps visible when an action requires approval or a verification step has not yet passed.
Forttic connects to the existing backup stack. The aim is to govern protection across connected clouds and vendors while teams continue using their backup platforms. See vendor coverage for how that connection works without rip-and-replace.
Tool access is not the operating system
An agent can retrieve status or invoke an approved action. Continuous Resilience Enforcement is the process that still has to detect drift, govern the change, verify recovery, and keep evidence current as the estate changes.
Choosing what to build and what to operate
For leaders considering a general-purpose agent, the useful evaluation is the complete operating system they will be responsible for.
Start with one resilience requirement and follow it through the environment. Determine how new workloads enter scope, how policy is applied, and how changes are detected. Then examine approval boundaries, failed actions, recovery testing, and evidence retention. Include the work required when a vendor changes an API or a workload gains a new dependency.
A custom agent can be part of that implementation. Its value should be assessed alongside the integrations, policy logic, verification processes, and ongoing maintenance needed to make the whole system dependable.
Forttic’s focus is this resilience-specific operating layer. Its architecture combines control knowledge, retained operational context, event triggers, and execution capabilities to support governed decisions.
The buyer’s question becomes more concrete: can we demonstrate that our required recovery state is being maintained across the systems we depend on?
Put continuous enforcement into your ResOps practice
AI can help teams investigate faster and automate more work. Those improvements become more valuable when they feed an operating process with clear ownership, controlled actions, and verifiable outcomes.
Start with a critical service and one protection requirement. Trace how your team notices a deviation, decides what to do, verifies the result, and records the evidence. Any unsupported handoff identifies work your resilience process still depends on someone remembering to complete.
Use the Forttic CRE assessment to identify gaps across discovery, assessment, enforcement, verification, and reporting.
Frequently asked questions
Can Claude or another AI agent manage backup tasks?
Yes, when the implementation provides suitable tools, permissions, and orchestration. An agent may retrieve status or invoke operational actions. A complete resilience system additionally needs policies, ongoing execution, exception handling, recovery verification, and evidence management.
Does connecting backup tools through MCP provide continuous resilience enforcement?
MCP enables applications to access exposed tools and data. Continuous enforcement depends on the system built around that connection: what it monitors, which policies it applies, how it governs changes, and how it verifies outcomes over time.
How is Forttic different from a general-purpose AI agent?
Forttic is designed around backup resilience governance across connected vendors and clouds. A general-purpose agent offers capabilities that developers can use in many applications. Building a comparable operating process requires resilience-specific integrations, controls, verification, and maintenance. See How Forttic Decides.
What does continuous resilience enforcement mean?
It means repeatedly reconciling the required resilience state with the observed environment, acting within defined boundaries when drift occurs, and retaining evidence of the result. Recovery testing can follow a schedule appropriate to workload criticality; “continuous” does not mean every workload is restored every moment. See What is CRE?.
Does Forttic make every change automatically?
No. Its CRE framework describes remediation within guardrails and escalation of high-impact actions for human approval. The scope of autonomy depends on the permitted action and configured controls.
Does Forttic replace existing backup platforms?
No. Forttic connects to the existing backup stack to govern resilience across connected systems. Backup platforms continue performing their backup and recovery functions. See vendor coverage.
Can AI agents and Forttic be used together?
They can serve complementary roles. Forttic publicly describes MCP and agent connectors. The available operations and permissions should be checked for the intended deployment; this article does not claim a specific packaged Claude integration.