Cybersecurity briefing
/
When an AI Workflow Changes, Its Approval Needs to Catch Up
When an AI agent repairs a workflow, its approval can go stale. Learn how to test, release and monitor changes before they reach production.
/
AUTHOR
Jeff Dyer
/
SHARE THIS ARTICLE
Overview
IBM and Microsoft announced Imagine Enterprise on November 10, a platform intended to help organizations build, operate and govern AI agents for industry-specific business processes. The announcement brings enterprise automation closer to the work executives actually want completed: moving information through existing systems and turning it into an operational result. It also raises a practical question for security leaders: when an agent changes the way a process runs, what happens to the approval that made the original process acceptable?
The companies describe an offering that combines IBM Consulting's agents and industry expertise with Microsoft's technology foundation. Those are announced capabilities, not independent evidence of reliable operation in every customer environment. The useful implication for buyers is that evaluating an enterprise agent now requires examining the lifecycle of the workflow it executes.
A repaired screen interaction can change a business process
Traditional automation often breaks visibly when an application changes. A field moves, a selector fails or a script stops. Adaptive computer-use agents offer a more flexible approach: they can interpret an interface and find another way to complete the task. That flexibility can reduce maintenance work, especially where a business depends on applications with incomplete APIs.
Security and operations still need to distinguish a harmless interface adjustment from a change in business meaning. Finding the same approved field in a new location is one thing. Choosing a different destination, skipping a validation step or substituting a new source of information changes the process that was reviewed.
Consider a hypothetical insurance operation that automates the preparation of a claim file. The workflow gathers documents, checks required fields and updates a case-management system. After a portal redesign, the automation discovers another route to submit the file. A technical test might establish that submission succeeded. The business owner must also establish that the revised route preserved the required review and attached the correct evidence.
The risk is not limited to malicious activity. An apparently successful repair can make an unauthorized process repeatable.
Separate workflow development from permission to deploy
Narada AI is a software company that automates multi-step business processes across applications, including browsers, desktop software and Citrix environments. Its platform combines API actions and computer-use agents so work can continue across systems that do not share a complete integration path. It addresses the operational burden of building and maintaining these workflows, with step validation, exception handling and human review available within the process.
Its October 16 introduction of Narada Code describes a development cycle that investigates applications, drafts a workflow and tests it in a sandbox. When execution fails, the software examines the run, revises the workflow and tests again. Operator or OperatorMini then executes the resulting instructions. This is a concrete mechanism for developing and maintaining automation, rather than simply asking a model to improvise every action.
The distinction between development and execution gives buyers a useful control boundary. A generated repair should be treated as a proposed change whose release depends on the organization's rules. A successful sandbox test establishes evidence for that decision; it does not automatically authorize broader production access. Exact application support and the deployment's versioning, promotion and rollback arrangements need validation before production use.
Test what the workflow must refuse
A release test should cover the business conditions that make an action acceptable. In the insurance example, that includes a missing document, conflicting identifiers and an attempted submission before review. The expected outcome may be a stop and an escalation. Counting every stopped run as a failure would reward the wrong behavior.
Keep those acceptance criteria outside the instructions that the development agent is free to revise. Otherwise, an automation can appear to improve by weakening the test it is supposed to pass. Changes to the criteria need their own accountable owner.
For a CISO, the same exercise should include attempts to redirect the workflow through untrusted page content or documents. Test whether the automation stays within its assigned systems, permitted data and approved actions. Restrict the execution identity to those actions, and keep development environments from inheriting production credentials unnecessarily. A sandbox with unrestricted production access provides little separation when an experiment goes wrong.
The release record should connect the workflow version to its tests, permissions and approval. Screenshots can help explain a failed interaction, but they may also contain sensitive information. Evidence retention and access therefore belong in the design, alongside the automation itself.
Keep the released version under observation
Applications, inputs and policies continue changing after deployment. NIST's March report on monitoring deployed AI systems explains why controlled pre-deployment evaluations need to be complemented by observation of real-world behavior. For business automation, that means checking completed records, unexpected destinations, exception patterns and changes in the amount of human review required.
Integralty's enterprise AI architecture and workflow development work can help translate those business conditions into deployment tests and operating responsibilities. The process owner should define an acceptable outcome; security should define access boundaries; operations should know when to suspend execution and return work to people.
Begin with one bounded workflow and require a reviewable change record whenever its behavior changes materially. Faster workflow development is valuable when the organization can explain what changed, why it was released and whether it still produces an authorized result. The approval needs to follow the process actually running today.
