AI agents are entering production environments — taking actions, making decisions, coordinating with humans and automated systems in ways that didn’t exist two years ago. The question for enterprises is how the autonomous work these agents do fits into the execution discipline that already runs the business. Agentic orchestration is the answer many enterprises are moving toward: a coordination layer that governs how autonomous agents operate within business processes, alongside the automated systems and human operators those processes already involve.

What is agentic orchestration?

Agentic orchestration is the coordination of AI agents, automated systems, and human reviewers within governed business processes. Unlike traditional workload automation, which executes predefined sequences of tasks, agentic orchestration coordinates work that combines rules-based execution with the judgment of AI agents, with consistent policy enforcement and visibility across both.

The orchestration layer doesn’t dictate every step. It provides the goals, defines what agents are allowed and not allowed to do, and gives them the tools and information they need to do their work. But it’s the agents themselves that figure out how to reach the goal within those limits. The result is a system where individual agents have room to make judgments — but the rules they operate under, the visibility into what they’re doing, and the accountability for what results stay under enterprise control. This combination is what makes agentic systems durable enough for production environments, where business workflows have to run reliably, prove auditable, and meet enterprise standards.

Most enterprises don’t introduce agentic orchestration as a replacement for what they already run. They add it to the orchestration layer they’ve been using for workload automation across applications, data pipelines, and cloud services — extending that layer to govern AI agents alongside the work it already coordinates.

How does agentic orchestration work?

Agentic orchestration begins with a defined goal — process a support ticket, execute a financial close, investigate a security alert — and a set of agents, automated systems, and human reviewers available to do the work. Different agents typically take different roles: A triage agent might categorize an incoming request; a research agent might pull information from internal systems or external sources; an executor agent might call an API to take a specific action. Each agent uses a defined set of tools that the orchestration layer makes available to it. The orchestration layer routes work to the right agent, gives the agent the context it needs, and tracks the state of the overall effort.

When an agent receives a piece of the work — investigate this anomaly, resolve this ticket — it typically breaks down the goal into a sequence of steps and works through them, adjusting the plan as it encounters new information or unexpected conditions along the way. The agent retains what’s happened across those steps — what it’s tried, what’s worked, what data it’s gathered — so that each action builds on what came before rather than starting from scratch. In more complex processes, agents also collaborate directly: one agent may delegate a subtask to another with the right specialization, or multiple agents may work different parts of a problem in parallel. The orchestration layer manages these interactions, tracking which agent is responsible for what and ensuring the overall process stays coherent as work moves among them.

When one stage of work is complete, the next stage usually involves a handoff — to another agent, to an automated system, or to a human for review or approval. The orchestration layer manages these transitions, carrying the relevant context forward, enforcing the policies that apply to the work in question, and recording every decision, tool call, and outcome at each step.

Some systems use this history to refine agent behavior over time. But whether or not learning is in scope, the audit trail is the foundation for accountability — it’s what makes governed autonomy possible at the scale production requires.

How does agentic orchestration relate to AI orchestration and AI agents?

Agentic orchestration is sometimes confused with related concepts. Here are the two distinctions that matter most.

How does agentic orchestration differ from AI orchestration?

AI orchestration is sometimes used as a catch-all term, but in practice it usually refers to something specific: coordinating the steps required to run AI models. A typical example is a fraud-detection system: A transaction comes in, the system enriches it with relevant history, and then an AI model scores the transaction for risk and a second model checks the customer’s recent behavior. The two scores get combined into a single assessment, and the result is sent to a downstream system. AI orchestration is what choreographs that sequence — what runs when, what data flows where, what triggers each model. The platforms that do this are built around the lifecycle of the AI models themselves: when they’re invoked, how their inputs and outputs connect to surrounding systems, and how their performance is tracked.

Agentic orchestration coordinates something different. The actors aren’t models running predefined steps, they’re autonomous agents pursuing goals — making judgments, choosing actions, working alongside automated systems and human reviewers inside a business process. Where AI orchestration manages a sequence of model calls, agentic orchestration coordinates and governs the actors themselves — agents whose paths aren’t fully defined in advance, because some of what they do gets decided as they go.

The two often coexist. The fraud-detection pipeline might be coordinated by AI orchestration, while the agent that detects a fraud pattern and initiates an investigation — pulling case history, contacting the customer, escalating to a human reviewer — operates within agentic orchestration. Both layers may run inside the same enterprise control plane, but they’re solving different problems: how an AI model should run as part of a larger flow of work, versus how autonomous agents should be governed as they do their work.

How does agentic orchestration relate to individual AI agents?

An AI agent is an autonomous actor — typically a large language model connected to a set of tools, given a defined goal to pursue, and able to take actions in the world to make progress toward that goal. Agents perceive their situation, decide what to do, and act through the tools they’ve been given. Each agent is typically specialized — built for a defined scope of work, with a defined set of tools, and a defined role within a larger process.

Agentic orchestration is the layer above the agents, managing the system the agents operate inside. The orchestration layer provides the goal to be achieved, allocates tasks among the available agents, determines which tools each agent can use, enforces the policies the work has to follow, manages handoffs between agents and other systems, and keeps track of what’s happened so the work stays coherent as it moves from step to step. It also records actions and decisions for visibility and accountability.

A single agent can complete a task. Multiple agents can complete related tasks in sequence or in parallel. Agentic orchestration is what coordinates those tasks — and the agents performing them — into a coherent, governed business process. It’s the layer that helps ensure the work as a whole completes reliably, transparently, and within the limits the enterprise has set.

How does agentic orchestration relate to traditional workload automation?

Agentic orchestration is best understood as an extension of the decades-old practice of workload automation — the next stage in the evolution of enterprise execution control.

The lineage from batch workload automation to agentic orchestration

That evolution has a recognizable shape. Enterprise execution began as batch workload automation — scheduled jobs running on predictable cycles, with dependencies managed across multiple systems. It expanded into application and data pipeline orchestration, coordinating workflows across the mix of systems most enterprises now run, including on-premises servers and multiple cloud environments. It grew to handle event-driven systems and cloud-native services, where work was triggered by signals rather than schedules. More recently, it has come to cover AI-powered workflows — where machine-learning models and AI-driven automation participate in business processes alongside everything else. Agentic orchestration is the next step: extending the execution layer to also coordinate autonomous agents that reason, plan, and act within the same business processes.

What carries forward is not just terminology but specific practices. The capabilities that mature workload automation platforms have developed over decades — dependency management across heterogeneous systems, SLA enforcement, retry and recovery logic, audit traceability, exception handling, observability across long-running workflows — are exactly the capabilities agent-driven workflows require to run reliably in production. The disciplines that make a financial close reliable when it consists of scheduled batch jobs are the same disciplines that make it reliable when it consists of a mix of scheduled jobs and AI-driven exception handling. The underlying execution layer doesn’t need to be rebuilt for agentic workflows; it needs to be extended to them.

What changes with agent-driven execution

What is genuinely new is the kind of work being coordinated. Traditional workload automation governs largely deterministic execution: predefined steps that follow defined rules and produce predictable outcomes. In general, the same job, run with the same inputs under the same conditions, should produce the same result. Agentic systems introduce non-deterministic execution: agents make judgments based on context, and similar situations can lead to different actions depending on the conditions the agent observes. Agents also introduce challenges that have no direct workload-automation precedent: the quality of the plans agents construct, the reliability of the reasoning behind their decisions, and the management of the memory and awareness that they carry across steps all require forms of oversight that traditional execution platforms were never designed to provide. Many production business processes now combine both. A financial close has dozens of deterministic steps (data extraction, scheduled reporting, file transfers) and a growing number of non-deterministic ones (anomaly investigation, AI-assisted exception handling, reprioritization when something upstream is late). Supply chain operations, customer service workflows, and IT remediation increasingly look the same way.

Mixed-execution processes are why agentic orchestration is best understood as an extension of the existing execution layer rather than as a separate AI-specific one. When agent-driven work is governed in one place and the deterministic work it coordinates with is governed somewhere else, the business process as a whole can end up with fragmented governance. Even if both systems enforced similar policies, the process crossing between them would have two separate audit trails to reconcile, two separate observability surfaces to integrate, and two separate state-management systems to keep in sync.

Coherent enterprise execution requires consistent governance across the whole process, for both operational and architectural reasons. A consistent governance layer reduces the cost of keeping connected systems in sync, helps policy changes propagate predictably, and produces a more coherent audit trail when the result has to be explained to an auditor, a regulator, a board, or an internal investigator.

How is agentic orchestration governed at enterprise scale?

Governance is what makes agentic orchestration different from agent experimentation. An AI agent operating in isolation can be unreliable in ways that are tolerable for a prototype; an agent operating inside a business process has to meet the same standards of reliability, accountability, and auditability as anything else running in production. Governance in this context isn’t a single capability. It’s a set of practices that together make autonomous execution safe enough to scale.

Five capabilities form the practical core:

Dependency control: Agent-driven work, like every other kind of enterprise work, has dependencies — on data being available, on upstream processes completing, on downstream systems being ready to receive results. The orchestration layer manages these dependencies across both deterministic and agent-driven steps, ensuring that an agent doesn’t act on stale data, that a downstream system isn’t asked to process incomplete inputs, and that the sequence of work — wherever the rules permit flexibility — still completes in a coherent order.

Policy enforcement: Every agent operates within defined constraints: what data it can access, what actions it can take, what thresholds require human review, what kinds of decisions it can make autonomously and which it must escalate. These policies are defined when agents are authored and enforced at runtime, not left to be implemented inconsistently by individual agents or development teams. Policy enforcement is what allows the enterprise to extend autonomy to agents without ceding control over what they do with it.

Observability: Production-grade agentic orchestration requires visibility into what’s happening across the full process — agent work and deterministic work alike. For agent work, that means tracking not just whether an agent completed its task but what actions it took, what tools it called, what AI model invocations it made, what data it accessed, and what outcomes resulted. For deterministic work, the requirements are the ones workload automation has long handled: job completion, dependency resolution, SLA performance, exception handling. Across mixed-execution processes, the orchestration layer has to bring these two kinds of observability together, because the signals each generates are different and the operations teams running the process need a single coherent view. The orchestration layer integrates those signals so operations teams can see the whole process at once, not just its individual parts.

Exception handling: Real business processes encounter conditions their designers didn’t anticipate — data that’s late, systems that are unavailable, situations that fall outside an agent’s defined scope. Exception handling in agentic orchestration combines retry and recovery logic familiar from workload automation with judgment-driven response from agents themselves, governed by clear escalation paths to human reviewers when the situation requires it. The result is a process that can absorb variability without losing its coherence.

Auditability: Every action taken by every agent — and every decision the orchestration layer makes about how to coordinate that action — is recorded with the context required to reconstruct what happened and why. Auditability is what makes governed autonomy demonstrable to regulators, auditors, and internal stakeholders. It’s also what makes systematic improvement possible: the audit trail is the data from which patterns of agent behavior, process performance, and recurring exceptions can be understood and addressed.

These five capabilities have to operate consistently across both deterministic and agent-driven execution — and across the points where the two interact. Coherent governance has to span the boundary between the two, not just hold on either side.

What are the core components of an agentic orchestration system?

A working agentic orchestration system typically combines several components, each with a defined role. The specifics vary by platform, but the underlying architecture is increasingly consistent across mature implementations.

Agents: The autonomous actors that perform individual units of work. Each agent has a defined scope — what kinds of tasks it handles, what tools it uses, what models it relies on, what decisions it can make on its own. Specialization is the norm; a system might include a triage agent, a research agent, an investigation agent, and an executor agent, each tuned for the work it’s meant to do.

Planning and reasoning: The capability that allows an agent to break down a goal into steps, decide what to do next based on what it knows, and adjust its approach as conditions change. Planning and reasoning are what distinguish an agent from a script — they’re what make it possible for the agent to pursue a goal rather than just execute a sequence.

Multi-agent coordination and delegation: The mechanisms by which work gets allocated and handed off among agents within a process. One agent may delegate a subtask to another agent with the right specialization, or multiple agents may work different parts of a problem in parallel. This is distinct from the control plane’s broader routing role — it’s the coordination among agents themselves, within the structure the control plane provides.

Control plane: The layer that routes work across the system, manages state (what’s happened so far, where each piece of work currently sits, what context needs to be carried forward), enforces policies, and coordinates handoffs between agents, automated systems, and human reviewers. This is the orchestration layer proper. It’s where the rules of engagement are enforced and where the audit trail is generated.

Tool registry: The central reference that defines what tools are available to which agents, with the appropriate access controls. Agents can access enterprise systems, APIs, data sources, and other resources through this registry, rather than through direct integrations that have to be configured for each agent. The registry is what makes governance manageable at scale: changes to access policies, new tools, or revoked permissions propagate consistently across the system rather than having to be applied agent by agent. The Model Context Protocol (MCP) — now backed by major AI vendors and governed by the Linux Foundation — enables agents to discover and connect to tools across systems, giving the registry a common interface rather than requiring custom integrations for each tool an agent needs to use.

Shared state and memory: The context preserved across the multiple steps that make up a coordinated process. An agent that takes the second action in a sequence needs to know what happened in the first; a downstream reviewer needs to see what the agent has already done. Shared state is what makes coordination across agents possible at all.

Human-in-the-loop mechanisms: Defined points at which humans participate in agent-driven processes — for review, for approval of consequential decisions, for handling exceptions the system can’t resolve on its own. These mechanisms aren’t a fallback for failure; they’re a structural component of the system, designed in from the start.

Audit and observability layer: The layer that captures the actions, decisions, and outcomes of every agent and every coordination event, in a form that’s query-able and retainable for compliance and operational analysis.

Together, these components form a system that can coordinate agent-driven work alongside everything else an enterprise runs, under coherent governance, with the visibility production requires.

What are common enterprise use cases?

Enterprise work increasingly combines deterministic, rules-based execution with adaptive, judgment-driven response. Below are three common examples — processes where governance has to span the boundary between scheduled work and AI-driven response.

Financial close and reconciliation: A financial close consists of dozens of scheduled, rules-based steps — data extractions, reconciliations, validation routines, reports. It also requires judgment when something doesn’t reconcile, when an anomaly appears, when an exception has to be investigated and resolved before the close can complete. Agentic orchestration coordinates AI agents that handle the exception-investigation work alongside the scheduled jobs that handle the predictable work, with full auditability across both.

Supply chain and operational continuity: Supply chain operations depend on scheduled coordination across procurement, inventory, logistics, and fulfillment systems. They also depend on adaptive response when something goes wrong — a delayed shipment, an inventory shortage, a routing change that affects downstream commitments. Agentic orchestration handles the coordination across the systems agents need to work with and gives agents the latitude to assess disruption signals, propose responses, and coordinate adjustments across the affected systems, all within policy boundaries set by the operations team.

IT operations and incident response: Modern IT environments combine deterministic automation (scheduled maintenance, automated patching, defined remediation playbooks) with situations that require judgment (incident triage, anomaly investigation, novel failure modes). Agentic orchestration coordinates AI-driven triage and investigation with the deterministic remediation playbooks already in place, escalating to human operators when the system reaches the limits of what it can resolve on its own. The result is faster response without loss of operational control.

What challenges does agentic orchestration introduce?

The challenges enterprises encounter when adopting agentic orchestration tend to be as structural as they are technological. They’re not only about whether the technology works; they’re about whether the organization has the architecture and discipline to deploy it responsibly.

Multi-agent coordination: Coordinating multiple agents across a complex process is harder than coordinating a single agent. Keeping track of what’s happened across multiple agents working in parallel gets more involved. Handoffs have to be defined clearly. The temptation to let agents communicate freely with each other has to be balanced against the need for the orchestration layer to maintain coherent visibility into what’s happening.

Observability across mixed execution: Producing a single coherent view across deterministic and agent-driven work requires the orchestration layer to make sense of two very different kinds of operational data: the predictable status updates that scheduled jobs generate, and the more varied signals that agent-driven work produces. Operations teams used to monitoring scheduled jobs have to extend their mental model to include those new signals — confidence levels, alternative paths the agent considered, decisions the agent escalated for human review.

Integration with existing systems: Agents typically need access to enterprise data and tools that were designed for human users or for system-to-system automation, not for autonomous agents. Integrating agents into existing environments — without bypassing the governance those environments enforce — requires careful work, particularly around identity, access control, and audit logging.

Operational discipline: The biggest challenge is often cultural. Operations teams used to deterministic systems sometimes treat agent-driven work as inherently less trustworthy, and either over-constrain it (eliminating the value of autonomy) or under-constrain it (creating governance gaps). Building the right practices for mixed-execution processes is mostly a matter of clear policy and experience — but it takes time, and it benefits from platforms that make those practices easier to enforce.

None of these challenges is unique to agentic orchestration as a category; they’re variants of challenges that enterprise execution has always involved. What’s new is the need to apply them to a kind of work that wasn’t prevalent in production environments a few years ago.

Control-M, BMC’s enterprise orchestration platform, the workload automation and workflow orchestration disciplines it has run for decades to coordinating agentic execution in enterprise environments. It holds agents to

In BMC’s view, the future of orchestration is not about AI agents or any other new technology. It’s about orchestrating the work — all the work, of agents, applications, data pipelines, and people — under coherent governance and through a single execution layer.

More on Control-M’s agentic orchestration capabilities is available here.

Control-M is named a Leader in the 2025 Gartner^® Magic Quadrant™ for Service Orchestration and Automation Platforms. Eighty percent of the Forbes Global 100 — across financial services, manufacturing, healthcare, retail, telecommunications, and the public sector — use BMC to coordinate the systems their businesses depend on.

Enterprise technology is moving quickly, but our customers are focused on a very practical question: how do we put new capabilities to work in ways the business can trust? 

That question is at the center of our July Control-M release. But more broadly, it reflects a shift we are seeing across the market. Increasingly, enterprises are realizing that innovation alone is not enough. What matters is how consistently and reliably that innovation is executed. This is why orchestration is becoming the control plane for modern enterprise operations. 

Helping customers put innovation to work

The new Control-M release reflects the operational realities our customers are navigating every day. As AI, automation, and cloud services become more central to business execution, teams need orchestration that helps them move new capabilities into production with more confidence and less complexity. 

That starts with practical AI: capabilities that help teams plan workflows faster, monitor with more insight, and get answers without chasing them across tools. It also means strengthening the governance and usability that make those capabilities dependable in daily operations. 

On the governance side, enhanced change management and ITSM interoperability bring workflow changes into the governed processes that the rest of the enterprise already depends on. As automation expands, governance has to expand with it. 

Turning innovation into trusted action

Several updates in this release bring that idea to life. They make AI more useful inside day-to-day operations, give agents a governed way to interact with enterprise workflows, expand the technologies Control-M can orchestrate, and strengthen the visibility and history teams rely on when they need to understand what happened and why. 

A key example is the Control-M MCP Server. MCP, the Model Context Protocol, is becoming an important way for AI agents to connect with enterprise systems. With Control-M MCP Server, agents have a governed path into Control-M: a way to trigger workflows, check status, and investigate issues without bypassing the security, auditability, and policy controls customers already trust us to enforce. That is what matters as AI moves from experimentation into business-critical operations. 

Innovation also must connect to the systems where work happens. In this release, we are continuing to expand Control-M’s reach across AI, data, cloud, and enterprise applications, including integrations with Azure AI Foundry, Dataiku, AWS RDS, Oracle Data Transform, SAP CPI, Azure VMSS, and more on the way. Every new integration helps reduce custom scripting and speed up onboarding of new technologies, bringing more of the environment into a single orchestration framework. Without that layer, teams are left stitching together scripts and point solutions that make execution harder to scale, govern, and trust. 

Once that work is in motion, trusted action depends on history, visibility, and accountability. That is why we are extending Control-M Archive Service to Control-M self-hosted customers. Archive Service gives teams a managed, more secure way to retain workflow history for audit, compliance, troubleshooting, and operational investigation. We are also introducing a refreshed user experience for Archive Service, making historical data faster to search, easier to navigate, and more useful when teams need answers quickly. 

Bringing innovation into real operations 

Taken together, practical AI, governed agent access, broader integrations, and extended Archive Service support all point in the same direction: helping customers bring new innovation into real operations with the trust, visibility, and control their businesses depend on. 

For Control-M, that means continuing to make orchestration smarter, better governed, more connected, and easier to use across the environments customers choose to run, so they can adopt what is next with confidence. 

As enterprises accelerate adoption of AI, automation, and cloud, the question is no longer what to adopt but how to run it reliably at scale. Control-M continues to evolve as the orchestration layer that turns innovation into trusted, business-ready execution, so organizations can move forward with confidence. 

To learn more about the latest release, join our webinar, “What’s New in Control‑M: Smarter Orchestration and a New Approach to Workflow Archiving.“

“While the announcement introduces a broad set of AI-powered capabilities, including workflow creation, operational copilots, self-hosted AI support, and Model Context Protocol (MCP) integration, the more important story is BMC’s continued investment in Control-M as an orchestration control plane capable of coordinating deterministic automation, event-driven workflows, data pipelines, and emerging AI agents under a common governance framework.” – Dan Twing, President and COO, Enterprise Management Associates (EMA)

Anthropic’s Claude Mythos has put mainframe security teams on notice. As a frontier AI model capable of autonomously identifying and chaining vulnerabilities at machine speed, Mythos represents a new class of risk for z/OS environments, dramatically accelerating the ability of adversaries to exploit any weakness present in the environment. While Mythos is the most visible example today, it represents a broader trend toward increasingly capable AI systems that are transforming vulnerability discovery and exploitation across the enterprise.  Traditional assumptions about the inherent security of the mainframe overlook operational risks such as misconfigurations, expired certificates, unmonitored privileged sessions, and delayed threat detection. To be Mythos-ready, organizations need to take active, end-to-end measures to reduce their attack surface and detect threats in real time.

Why Claude Mythos poses a threat to the enterprise

By acting as an autonomous agent capable of independent, multi-step actions, Mythos can identify and link multiple security flaws into a programmatic chain of exploitation. As a result, time-to-exploit can collapse from weeks or months to hours or days, making vulnerability discovery and exploitation effectively simultaneous. These capabilities lower technical barriers and enable motivated actors with modest resources to perform multi-step exploitation that historically required elite specialists. Mythos has already found thousands of high-severity vulnerabilities across major operating systems and web browsers, including one vulnerability that had been present in a system for 27 years.

Global leaders are taking this threat seriously. Canadian Finance Minister François-Philippe Champagne described Mythos as an “unknown unknown” that warrants the attention of all finance ministers. Bank of England Governor Andrew Bailey has said his institution is carefully examining what it means for the risk of cybercrime.

Project Glasswing is a temporary measure at best

Formed in response to the risk of Mythos weaponization, Project Glasswing is a narrow, defensive consortium led by Anthropic with more than 50 member organizations. The group’s intention is to use Mythos to find and patch vulnerabilities in critical software while the model remains withheld from general availability. While Project Glasswing aims to give security teams time to reorganize their defenses, this window won’t hold forever, and its partners may not be able to fix all vulnerabilities in time.

In fact, reporting indicates that an unauthorized group has already accessed Mythos through a data breach at an AI training startup combined with contractor access to Anthropic’s systems, demonstrating that access restrictions alone cannot be relied upon. Rivian CISO Mike Johnson has warned that “by the end of the year, Mythos-level capabilities will be in the hands of any attacker.”

Organizations can’t rely solely on rollout restrictions imposed by AI developers. Mainframe security teams have to work proactively to reduce the risks posed by Mythos.

Why platform strength isn’t enough

The mainframe has traditionally offered security advantages such as physical isolation, proprietary architecture, and granular access controls. But unless this platform strength is complemented with the right operational security capabilities, including automation, monitoring, and lifecycle management, that strength won’t translate into real-world security outcomes.

To actively protect the mainframe end-to-end, mainframe security teams must address risks including:

• API-based threats: Attackers can hijack trusted API connections between distributed systems and the mainframe, exploiting machine-to-machine authentication to reach mainframe data directly.
• Identity-based threats: Credential theft, insider threats, and privilege escalation, already among the most common attack vectors across platforms, are turbocharged by AI-driven phishing and social engineering; machine identities including service accounts and API keys represent an additional and often under-protected attack surface.
• Software supply chain attacks: Third-party involvement in breaches doubled in a single year. Compromised mainframe development tools, vendor software, and shared CI/CD pipelines all represent potential entry points.
• Lateral movement: Once a distributed system is compromised, existing trusted connections including database links, shared credentials, and network pathways can be used as a stepping stone to the mainframe.

Operational gaps such as expired or misconfigured certificates, unmonitored privileged sessions, outdated software versions, and manual security processes can make these threats more exploitable. As AI-driven attack capabilities continue to evolve, staying current on supported BMC AMI Security software versions and adopting new protections quickly becomes increasingly important.

Preparing Mainframe Security for AI-Accelerated Threats

AI-accelerated threats increase the cadence of attacks, expand the scope of vulnerability discovery across hybrid environments, and compress the time available for security teams to respond. As Mythos-level capabilities proliferate, ISACA, a global, independent non-profit association focused on digital trust, calls for organizations to adopt continuous exposure management. With this approach, security teams correlate findings with runtime topology and business criticality in real time to close the operational gaps that advanced threats exploit.

This shift also reflects what organizations such as FNTS are seeing in the field: compliance reporting alone is no longer enough. Security teams need operational security capabilities that provide continuous visibility, real-time monitoring, and rapid response across the hybrid enterprise. In the Mythos era, organizations must move beyond periodic audits and static controls to actively detect, investigate, and contain threats before automated attacks can escalate

BMC AMI Security helps close these operational gaps across key threat categories facing the mainframe:

• Delivering faster forensic investigations with real-time visibility and session auditing: BMC AMI Command Center for Security provides an affordable mainframe-native SIEM for immediate visibility into z/OS security incidents. BMC AMI Datastream streams mainframe security events into enterprise SIEMs in real time, eliminating the mainframe security silo and enabling coordinated detection of lateral movement across the hybrid environment. BMC AMI Security Session Monitor delivers continuous auditing of application and data access to detect session-level anomalies before they escalate. Together, these capabilities turn enriched, real-time security data into the speed of response that the Mythos era demands.

• Protecting against API-based threats with certificate lifecycle management: Certificate-based authentication provides stronger protection against API-based threats than API keys alone, but only if certificates are kept current and correctly configured. As certificate lifetimes shorten toward 47 days by 2029, manual certificate management creates an unacceptable operational risk. BMC AMI’s integration with enterprise certificate infrastructure automates certificate lifecycle management across the hybrid environment, preventing vulnerabilities resulting from expired or misconfigured certificates.
• Protecting against identity-based threats with behavioral monitoring, MFA, and privileged access controls: As threats accelerate, organizations must be able to identify stolen credentials and rogue users immediately before an automated attack can escalate. BMC AMI User and Entity Behavior Analytics (UEBA) monitors both human and machine identities under an assumed-breach posture, using AI-driven behavioral baselining to detect anomalies such as unusual login times, abnormal data access, and anomalous query patterns that signal credential misuse. MFA support via Okta extends enterprise authentication standards to mainframe access. Privileged Access Management further reduces risk by enforcing controlled, auditable access to critical systems, commands, and sensitive data.
• Protecting against supply chain attacks with DevSecOps integration and file integrity monitoring: BMC AMI DevSecOps integration supports code signing and hashing verification, ensuring that mainframe deployments carry the same supply chain security controls as distributed systems. File Integrity Monitoring (FIM) capabilities detect and remove malware from recovery sites during restoration, with change management controls providing a full forensic audit trail of what was deployed, when, and by whom.
• Reducing exploitable gaps with AI-driven penetration testing and exposure assessment: Traditional periodic testing is no longer sufficient against autonomous, AI-accelerated threats. AI/ML penetration testing helps organizations identify vulnerabilities across LLMs, APIs, applications, identities, and hybrid infrastructure before attackers can chain them together into real-world exploits, enabling security teams to proactively remediate weaknesses and strengthen operational resilience.

Limiting the blast radius: Zero Trust and resilience

As mainframe teams work to strengthen their security posture against Mythos-enabled attacks, they must also ensure the resilience to mitigate the impact of any incident that does occur. The Cloud Security Alliance (CSA) advises organizations to verify and enable mitigating controls such as segmentation, egress filtering, Zero Trust architectures, and phishing-resistant MFA to limit post-exploitation impact.

AMI Security provides essential capabilities to address these requirements.

• BMC AMI Enterprise Connector for Illumio brings the mainframe into enterprise Zero Trust with automatic micro-segmentation, restricting lateral movement even when a distributed system has been compromised.
• Immutable Cloud Vaults prevent data tampering and ensure forensic recovery. Transaction logs are streamed continuously off-platform—even to on-premises object storage—to enable no-data-loss recovery even if the mainframe environment is compromised.
• Automated Forward Recovery restores lost transactions post-attack, supporting the tight recovery windows required under frameworks such as DORA.

What AI-resilient security means in practice

While Mythos may be the first widely discussed example of autonomous AI-driven cyber exploitation, it is part of a broader wave of increasingly capable models that are accelerating the pace of cybersecurity risk. This makes established best practices even more critical. The UK AI Security Institute has noted it cannot confirm whether Mythos Preview would be able to attack well-defended systems, reinforcing that strong, active defenses remain the most effective response.  As autonomous AI models continue to emerge and proliferate, organizations must shift from static audits to continuous, real-time defense, with active management of certificates, identities, sessions, and supply chain integrity across the full hybrid environment.

However the Mythos story evolves, it’s clear that mainframe teams will continue to see new types of threats and rising risk. By strengthening security across your mainframe attack surface with end-to-end technologies and operational capabilities, you can protect your organization more effectively against whatever the future holds.

Explore how BMC AMI Security helps identify vulnerabilities, monitor privileged activity, and reduce exposure before threats become incidents.

SAP mainstream maintenance for ECC ends December 31, 2027. Moving to S/4HANA protects your ERP investment, but only if the business processes around SAP keep running. Control-M is the enterprise orchestration layer that coordinates SAP and non-SAP workflows so execution stays reliable through the change.

The countdown is real. For the estimated 17,000 organizations still running ECC, that deadline is no longer a distant milestone. It’s a planning problem that needs an answer now.

The move to S/4HANA is more than just a technical upgrade. It’s a shift from stable, system-centric operations to dynamic, interconnected processes that span cloud services, data platforms, and external partners. Your SAP investment only delivers value when everything around SAP works, and that’s specifically where migration risk hides.

Why does S/4HANA migration increase execution risk?

Most transformations involve a dual-run period, where ECC and S/4HANA operate in parallel while teams work toward cutover. During that window, a single financial close or order-to-cash cycle can span SAP, data platforms, cloud services, and non-SAP applications, each with its own dependencies and timing.

When those workflows are managed in siloed tools, three problems surface fast:

• Cross-system dependencies break down. Processes that depend on coordinated handoffs between SAP and connected systems fail in ways that aren’t obvious until they hit business outcomes.
• Visibility fragments. Teams lose a unified view of what’s running, what’s blocked, and what’s at risk.
• Recovery becomes manual. Disconnected tools mean more effort and more chances for late or failed processes.

The work that looks stable inside SAP can still collapse across the systems SAP depends on.

How Control-M protects your SAP investment

SAP runs your core business processes. But when those processes span systems, coordination breaks down. Control-M is the enterprise orchestration layer that ensures reliable, end-to-end execution across SAP and dependent systems. It’s not a better SAP scheduler, but the layer that governs the full business workflow.

During migration, Control-M orchestrates workflows across ECC and S/4HANA simultaneously, manages parallel execution, and coordinates cutover, reducing disruption risk. After go-live, it keeps financial close, data movement, and cross-platform workflows running as coordinated processes rather than disconnected jobs. And as legacy SAP automation tools reach end of support, Control-M consolidates automation into one governed control plane with unified SLA tracking and audit-ready visibility.

What results have organizations seen?

• REWE digital shifted its entire distribution system to Control-M with zero downtime. At 23:59 on go-live, the original vendor’s tool ran its last workflow. One minute later, Control-M launched all workflows across every fulfillment center.

• Coop manages 107 SAP instances and 140,000 job runs a day with only three administrators.

• Snam reduced workflow errors by 40 percent after consolidating data and application workflows in Control-M.

These gains are the difference between a migration that protects the business and one that puts it at risk.

Protect the investment before the deadline

The 2027 deadline is about protecting the processes your business runs on. Modernization increases complexity, and complexity left ungoverned becomes operational risk.

Control-M ensures those processes continue to run reliably through the change. SAP manages the core. Control-M makes sure the full business service executes on time and within policy, across every system involved.

If you’re planning your move to S/4HANA, see how Control-M can ease and accelerate your migration.

Frequently asked questions

When does SAP ECC maintenance end?

SAP provides mainstream maintenance for ECC 6.0 (enhancement packages 6–8) until December 31, 2027. Many organizations are choosing a migration path now to avoid rising costs and a compressed timeline.

Why is S/4HANA migration considered risky?

The main risk isn’t SAP itself. It’s execution across connected systems. During dual-run periods, coordinating workflows with fragmented tools leads to broken dependencies, lost visibility, and manual recovery.

How is Control-M different from SAP-native scheduling?

SAP-native tools manage jobs within SAP. Control-M coordinates the full business process across SAP and non-SAP systems, mapping dependencies, enforcing SLAs, and providing unified visibility across the entire workflow.

Do we have to replace our existing tools to use Control-M?

No. Control-M acts as a unifying orchestration layer without forcing a rip-and-replace. It consolidates fragmented automation over time, which is especially valuable as legacy SAP automation reaches end of support.

Modernizing your orchestration platform during an SAP S/4HANA migration protects existing automation investments, closes integration gaps across hybrid landscapes, and creates a governed control plane for AI workflows. Doing both together reduces dual-run risk and helps critical business processes run reliably through change and after go-live.

SAP runs the core processes that keep a business moving: financial close, order flows, supply chain, and reporting. But those processes rarely stay inside SAP. They reach into data platforms, cloud services, mainframes, and dozens of non-SAP applications. When you migrate from ECC to S/4HANA, the systems your workflows depend on shift too, and the coordination between them gets more fragile.

That’s the part many migration plans overlook. Teams focus on the ERP move itself, then assume their existing automation will behave the same way in the new environment. It usually doesn’t. New complexity (multi-cloud execution, longer dependency chains, parallel ECC and S/4HANA operation) changes how workflows perform. The result is missed SLAs, manual recovery, and the kind of late-night escalations no one budgets for.

This post explains why your orchestration platform deserves attention at the same time as your S/4HANA migration, not after it. You’ll learn how modernizing both together protects what you’ve already built, supports emerging AI-driven work, and keeps business processes running predictably through one of the biggest transitions your organization will face.

Why modernize SAP orchestration during migration?

A migration to S/4HANA is rarely a clean, single-day switch. Most organizations run ECC and S/4HANA in parallel for a stretch, coordinating cutover and validation across both. That dual-run period is where execution risk spikes. You’re managing timing, dependencies, and handoffs across two ERP environments plus everything connected to them, often with disconnected tools and a lot of manual effort.

Modernizing orchestration at the same time gives you a single control plane to manage that complexity. Instead of stitching together SAP-native schedulers and siloed point tools, you coordinate end-to-end business processes across ECC, S/4HANA, and dependent systems from one place. You see what’s running, what’s blocked, and what’s at risk before it affects the business.

Treating orchestration as a separate, later project tends to backfire. Execution coordination is hardest to fix once fragmentation is already entrenched. Addressing it during the migration, when you’re already redefining how work runs, means you build the new environment on a stable foundation rather than retrofitting one under pressure.

The forcing function: legacy automation reaching end of support

There’s a practical reason this conversation is happening now. Legacy SAP automation tools are reaching end of support, which pushes many organizations into a replacement decision they can’t defer. Rather than swapping one siloed scheduler for another, this is the moment to adopt an enterprise-wide orchestration layer that consolidates SAP and non-SAP execution under unified control, without rebuilding the same workflows in a tool that only understands SAP.

Protect the automation investments you’ve already made

Here’s the concern that keeps IT leaders up at night during a migration: years of carefully built automation suddenly at risk. You’ve invested time and budget into workflows that span SAP, data pipelines, file transfers, cloud services, and homegrown applications. Moving to a SAP-specific tool often means rebuilding much of that from scratch, which adds cost, delay, and risk to an already demanding project.

Modernizing with an enterprise orchestrator preserves that work. Control-M brings your existing non-SAP automation and your new S/4HANA workflows into the same control plane, so you extend what you’ve built rather than recreate it. With more than 100 native integrations covering AWS, Azure, Google Cloud, Oracle, Informatica, Kubernetes, Databricks, Apache Airflow, and many more, the workflows surrounding SAP keep running while the ERP environment changes underneath them.

The financial logic is straightforward. SAP S/4HANA migration projects already carry significant investments across planning, licensing, resources, and implementation. Folding orchestration modernization into the same program reduces the number of follow-on upgrade projects later, and the savings can be redirected elsewhere in the business. Investment protection isn’t only about preserving old work. It’s about getting more value from the project you’re already funding.

AI agents need governed orchestration, not free rein

SAP is moving fast into AI-assisted operations. SAP Joule and intelligent agents built on the SAP Business Technology Platform (BTP) can generate decisions, trigger actions, and interact with APIs across systems. That’s powerful, but business value doesn’t come from isolated intelligent components acting on their own.

Agent-driven workflows are dynamic, cross-platform, and sensitive to compliance requirements. They need a structured, observable, and accountable layer to sequence execution, enforce SLAs, and maintain an audit trail of what ran, when, and with what outcome. Without that governance, AI activity becomes another source of risk rather than a source of value.

This is where orchestration earns its place in your future architecture. Control-M orchestrates event-driven and AI workflows within governed business services, so intelligent systems operate inside guardrails instead of around them. If you’re audited tomorrow, you can show what executed and whether it met policy. As more AI enters production, accountability becomes essential rather than optional.

The migration challenges that orchestration solves

The more established an organization is in SAP ECC, the harder the transition tends to be. A few recurring challenges show up across nearly every migration:

• Accumulated integrations. Over years, companies have built up a growing web of integrations with their SAP systems. Managing all of them during a migration pulls focus away from the project itself and creates more places for things to break.

• Complex landscapes. Many organizations run multiple ERPs, add-ons, non-SAP systems, and custom scripting. If any associated job or process breaks during migration, operations can grind to a halt, costing real time and money.

• Clean core pressure. SAP’s clean core strategy moves custom logic and integrations out of the ERP and into the surrounding landscape. Without a capable orchestration layer to manage those externalized workflows, teams end up with new coordination gaps where the old customizations used to be.

• No plan for ongoing automation. Teams often keep running automation the way they always have. During migration, that lack of forward thinking leads to gaps as workflows move to S/4HANA.

Each of these comes down to the same root issue: execution that spans systems without coordinated, end-to-end control. A modern orchestration layer addresses all three by mapping dependencies, sequencing execution, and giving teams one view across the whole process lifecycle.

How Control-M supports your S/4HANA migration

As an SAP-certified solution, Control-M creates and manages SAP ECC, S/4HANA, and BW jobs, plus data archiving, and supports any application in the SAP ecosystem. It connects to SAP through the SAP-certified BC-XBP interface, and both the self-hosted and SaaS versions are SAP Certified for Integrations with RISE with SAP S/4HANA Private Cloud. Here’s what that delivers in practice:

• Reduced project time and cost. Pre- and post-migration automation keeps operations smooth and consolidates modernization into one program, cutting the number of follow-on upgrade projects.

• Reduced integration complexity. Control-M provides a complete integration view across SAP and non-SAP systems, so data flows and dependencies stay coordinated through the transition.

• End-to-end visibility and governance. Real-time monitoring, SLA management, and full execution traceability give teams the control and audit readiness modernization demands.

• Scalability and stack alignment. Control-M scales with the business and sets a clean foundation for the innovation projects that follow migration.

Proof that this approach works

Two examples show what reliable orchestration looks like during high-stakes change.

When REWE digital migrated its mission-critical distribution systems, the cutover was seamless. At 23:59 on go-live, the previous automation tool ran its last workflows. One minute later, at 00:00, Control-M launched every workflow, managing orders to all fulfillment centers across the company’s markets. The entire distribution system shifted with zero downtime, no small feat when thousands of supermarkets depend on it.

Coty, one of the world’s largest beauty companies, uses Control-M to automate and orchestrate its most critical business processes. By consolidating onto a single orchestration platform, Coty streamlined execution across its environment and sustained high process reliability. This is clear evidence that unifying fragmented automation pays off in day-to-day operations, not just at cutover.

Build the foundation before you need it

A migration to S/4HANA succeeds only when workflows run reliably, make daily work better for business users, and support what the enterprise wants to build next. Your ERP can be perfectly migrated and still fall short if the processes around it stumble.

Modernizing orchestration alongside your S/4HANA migration protects the automation you’ve already invested in, simplifies the integrations that make migration risky, and prepares your environment for AI-driven work that needs governance to be safe. The organizations that handle both together don’t just survive the transition. They come out of it with a stronger foundation for everything that follows.

To see how Control-M can de-risk your S/4HANA migration and strengthen your broader SAP workflows, visit the Control-M for SAP website.

Frequently asked questions

Why should I modernize orchestration during an SAP S/4HANA migration instead of after?

Migration is when execution risk is highest, because you’re often running ECC and S/4HANA in parallel and coordinating cutover across connected systems. Modernizing orchestration at the same time gives you one control plane to manage that complexity. Waiting until after means retrofitting coordination once fragmentation is already entrenched, which is harder and costlier.

How does Control-M protect existing automation investments?

Control-M brings your existing non-SAP workflows and new S/4HANA jobs into a single control plane, so you extend what you’ve built instead of rebuilding it in an SAP-only tool. With more than 100 native integrations, the automation surrounding SAP keeps running while the ERP environment changes.

What does the end of support for legacy SAP automation mean for my migration plan?

It forces a replacement decision you can’t postpone. Rather than swapping one siloed scheduler for another, you can use the moment to consolidate SAP and non-SAP execution into one enterprise orchestration layer, reducing tool sprawl and avoiding a rebuild later.

Is Control-M certified to work with SAP and RISE with SAP?

Yes. Control-M is an SAP-certified solution that manages SAP ECC, S/4HANA, and BW jobs through the SAP-certified BC-XBP interface. Both the self-hosted and SaaS versions are SAP Certified for Integrations with RISE with SAP S/4HANA Private Cloud.

Data plays an integral role in the success of modern businesses. In an SAP ecosystem, data must flow across multiple inbound and outbound sources. To make things even more complicated, gathering and processing data, and then delivering insights, often requires orchestration of data and applications across multiple SAP and non-SAP systems. And as companies enact plans to migrate from legacy SAP systems to SAP S/4HANA^®, failure of critical SAP data flows can bring those digital transformation and modernization efforts to a screeching halt. Missing business modernization deadlines could have long-lasting ramifications, including additional maintenance costs and less-inclusive approaches.

Without a solid data orchestration strategy to ease the process, SAP data orchestration can get difficult quickly. Orchestrating and monitoring data flow within SAP systems is challenging due to factors like integration complexity, data quality, performance, and scalability issues. Monitoring data workflows through multiple SAP and non-SAP systems can also create a range of difficulties, from a general lack of workflow visibility to the inability to address dataflow failures in a timely manner. In addition, SAP data engineers must manage complex environments with multiple integrations and interoperability, often while trying to keep up with frequent changes in business requirements and technologies. All this work, and the troubleshooting required to find data and job failures, leads to more time and money being spent to get everything back on track.

How Control-M Can Help

Control-M provides the workflow orchestration capabilities to help organizations streamline their SAP dataflows in parallel with their migration to SAP S/4HANA. As an SAP-certified solution, Control‑M orchestrates non‑SAP and SAP workflows (including SAP ECC, S/4HANA, and SAP BW jobs) within a single platform. It provides out-of-the-box visibility to all enterprise workflows and their dependencies across SAP and non-SAP source systems and de-risks the transition to SAP S/4HANA.

With unified scheduling and automation of workflows with both SAP and non-SAP systems, Control-M can help organizations greatly reduce time to value, complexity, and the requirement for specialized knowledge. It can also be used for all other enterprise jobs, services, processes, and workflows. That lets businesses using SAP build, orchestrate, run, and manage all their enterprise jobs from a consolidated, integrated platform. In addition, Control-M easily adapts to changing business and technology requirements, ensuring that data processes remain consistent across systems and platforms and aligned with organizational goals. And as resources fluctuate, Control-M can help allocate them effectively, optimizing system capability usage and reducing bottlenecks.

Control-M can serve as a comprehensive platform because of its many integrations. The solution can support all SAP versions and job types. It also supports many other enterprise workflows and has more than 100 native integrations with popular tools, including Amazon Web Services (AWS), Azure, and Google Cloud (and many of their components), Oracle, Informatica, SQL, Red Hat, Kubernetes, Apache Airflow, Hadoop, Spark, Databricks, UiPath, OpenText (Micro Focus), Alteryx, and many more.

Robust data orchestration is crucial to the success of your SAP workflows, especially when they include both SAP and non-SAP systems. Complexity can increase quickly, making it difficult to keep up and hard to manage, and ultimately, leading to missed service level agreements (SLAs). With Control-M, organizations can cut through complexity and have full visibility and control of their application and data workflows.

If you’re interested in learning more about how Control-M can help you with SAP dataflows and much more, check out our website.

AI is changing where risk shows up—and making it harder to prove you’re in control.

TL;DR

AI agents, APIs, and automated workflows are scaling faster than the controls designed to govern them. Fewer processes involves people, but most controls still assume they do.

Policies exist. Monitoring exists. But control rarely happens at the moment work runs.

That’s the gap.

If you can’t prove—right now—what executed, what data was used, and whether it followed policy, you don’t have real-time compliance. You have delayed reporting.

What Do We Mean by “Real-Time Compliance”?

Practically speaking, it’s pretty simple: Can you tell me—right now—what ran, what data it used, and whether it followed policy? If you can’t answer that without digging through logs or pulling reports later, it’s not real-time.

Real-time compliance means control is applied as work runs—not before on paper, and not after in an audit. And the proof is created at the same time, automatically.

If you have to reconstruct what happened after the fact, you’re not operating in real time. You’re piecing together history.

The Real Problem: Control Isn’t Applied Where Work Happens

Most organizations aren’t missing controls. You likely already have:

• IAM to define who can access what
• Security tools to detect issues
• Governance frameworks to set policies

The problem is that these systems don’t actually control what happens when work runs across workflows, data pipelines, or AI systems. As a result, gaps show up in production:

• Machine-driven activity grows, but enforcement isn’t consistent
• Data pipelines move faster, but validation gets weaker
• AI systems follow policies on paper, but not always in practice

And when someone asks, “Are we compliant right now?” you still can’t answer in real time. It can take hours, days, or even weeks.

A Quick Litmus Test: Is Control Enforced?

If you’re accountable for risk and compliance, there’s a simple way to pressure-test your current state: Check the boxes where you can prove control at execution—not just in policies or audit reports.

Machine & AI execution

• You can list every non-human identity running production workflows
• You can trace every AI-driven action to a system and dataset
• Policies are enforced before execution, not just logged afterward

If not, machine activity is happening outside enforceable control—and you can’t reliably audit it.

Data and AI pipelines

• Every production pipeline includes enforced validation checkpoints
• You can prove lineage from source to output
• AI systems cannot run on unapproved or external data

If not, decisions are being made on data you can’t fully trust or defend.

Compliance proof

• You can generate evidence in real time without manual effort
• Audit trails are system-generated, not assembled afterward
• You can answer “are we compliant right now?” with actual data

If not, compliance is reactive and hard to defend under scrutiny.

The takeaway: If you can’t check every box in a category, control in that area isn’t enforced at execution. And if you see gaps across categories, you’re not preventing risk, you’re discovering it after the fact.

Where Real-Time Compliance Breaks Down

In most environments, the issue is that controls aren’t applied where the work actually runs.

Here’s where it typically breaks down:

1. Identity control stops with people

IAM works well for humans, but most production activity now isn’t driven by people. It’s service accounts, APIs, automated workflows, and AI agents doing the work. These identities often aren’t consistently governed, aren’t tied to enforceable policies at runtime, and aren’t monitored at the point of action. So, while access may be controlled, execution isn’t.

2. Data pipelines outrun your controls

Pipelines are built to move fast. Controls are often layered around them, not inside them. That leads to validation being optional, policies being applied inconsistently, and outputs being built on unverified inputs. So, you might have lineage—but not trust in the outcome.

3. AI governance stops at definition

Most organizations have started defining model policies, access controls, and governance frameworks. But they don’t control how AI actions are triggered, what data is actually used, and how decisions propagate through systems. So, policy exists, but enforcement doesn’t.

What It Takes to Prove Compliance

At some point, this becomes a practical question: Can we prove what happened, as it happened? To do that, control has to move closer to execution, where works runs.

That means having a layer that:

• enforces policy before execution
• validates data as it moves
• governs AI workflows like any other production process
• captures evidence as part of execution—not afterward

When that exists, questions like these are easier to answer:

• What ran across our environment in the last 24 hours?
• Which workflows used unvalidated data?
• Where were controls bypassed?
• Which AI-driven actions violated policy?
• Are we compliant right now?

If you can’t answer these questions quickly, control is assumed—not enforced.

What Real-Time Compliance Requires

Frameworks like the EU AI Act and NIST AI RMF aren’t asking for more documentation.

They’re asking for provable behavior. To meet that bar, four things need to be true:

1. Controls are enforced at execution

Non-compliant workflows don’t run. Policies apply consistently. Every execution records whether it passed or failed control.

2. Data and decisions are traceable

Every output can be traced back to its data sources, transformations, and execution path. Across systems, not just within tools.

3. Compliance is continuous

You don’t check compliance periodically. You can see what’s running, under which policies, in real time.

4. Evidence is generated automatically

Audit trails aren’t reconstructed. They’re created as part of execution. If compliance depends on reconstructing events, it won’t hold up under real pressure.

What This Looks Like in the First 90 Days

Achieving real-time compliance isn’t a multi-year transformation. It starts with visibility into where control breaks down, and then quickly moves to enforcing control at execution.

Days 0–30: Visibility

• Identify critical workflows
• Surface unmanaged machine and AI activity
• Map where execution happens outside control

Outcome: You know where compliance can’t be proven right now.

Days 30–60: Enforcement

• Bring high-risk workflows under orchestration
• Introduce policy checkpoints
• Apply validation to key pipelines

Outcome: High-risk execution is now governed at runtime.

Days 60–90: Proof

• Automate evidence generation
• Establish continuous compliance baselines
• Link workflows, data, and outcomes

Outcome: You can prove compliance as work runs, not after. 

Common Questions Security & Risk Leaders Ask

1. How do we find where controls are being bypassed?

You need visibility into execution, not just policy definitions. That usually means centralizing orchestration and making workflow execution observable across systems.

2. How do we keep AI agents within bounds?

By enforcing controls at runtime: identity, data access, and allowed actions. Every action must pass through those controls, not just inherit policy.

3. How do we add human approvals without slowing everything down?

By applying them selectively. Most workflows run automatically. Only exceptions or high-risk actions trigger human approval in real time.

4. How do we prove what happened without manual reconstruction?

By capturing execution as it happens: inputs, transformations, model activity, outputs. All in a single, time-sequenced record.

Final Thoughts: The Mental Shift That Matters

Compliance used to be about documentation. Now it’s about provable execution. The question isn’t “Do we have policies?” It’s “Can we prove they were enforced when work actually ran?”

That’s where an AI control plane approach starts to matter.

Platforms like Control‑M bring execution, control, and evidence together, so you can:

• Enforce policy at execution, not after the fact
• Validate data before it’s used
• See exactly what ran, how it ran, and what it produced
• Capture audit evidence automatically, as part of runtime

When that’s in place, everything tightens up: Work runs under control, activity is visible in real time, policies are applied consistently, and compliance is provable without reconstruction.

Final takeaway: If you’re trying to move from “we think we’re compliant” to “we can prove it right now,” it starts with enforcing control where execution happens.

How to operationalize AI governance to control risk and compliance in production

TL;DR

AI isn’t the hard part anymore. Operationalizing AI is.

Most AI projects stall because no one really has control over how the whole thing behaves in production.

Pipelines run. Workflows exist. But they’re stitched together across tools, scripts, and “somebody who knows how it works.” What you have isn’t a system. It’s coordination by coincidence.

A SOAP is the layer that turns all of that into something you can actually run and rely on.

Why So Many AI Projects Stall — and What’s Missing in the Middle

The model works. The use case is valid. And then it stalls. Not because the model failed, but because everything around it starts to break.

The problem shows up in the middle:

• data isn’t where it needs to be
• steps don’t run in the right order
• systems drift out of sync

Individually, those pieces exist. Together, they don’t behave like a system. That’s why “we got it working” rarely turns into “this runs reliably in production.”

There’s a layer that’s supposed to hold all of this together. In most environments, it doesn’t exist as a single system. It’s spread across schedulers, pipelines, scripts, and a lot of tribal knowledge.

When you actually pull that together into something coherent, it’s what’s referred to as a Service Orchestration and Automation Platform (SOAP).

Is SOAP Just Rebranded Orchestration?

It sounds like it. Most teams already have plenty of orchestration. And yet the common experience is: everything runs but it still doesn’t feel under control.

That’s because orchestration is built to execute workflows—even across systems—but it doesn’t inherently give you control over how those workflows behave at the system level.

The problem is that real systems don’t stay in boundaries. Workflows interact. Dependencies cross tools. Upstream delays ripple. AI steps behave inconsistently. So you end up here: everything ran, but the outcome is still wrong.

That’s not an execution failure. It’s a control failure. That’s the shift:

• Orchestration defines how the workflow is supposed to run across systems.
• SOAP is what actually keeps those workflows running correctly across the environment.

You don’t feel that difference when you’re building a pipeline. You feel it when:

• that pipeline connects to everything else
• something upstream is late
• something downstream quietly breaks
• and no single tool can explain what actually happened

In practice, this is where platforms like Control‑M show up—not as “another orchestrator,” but as the layer that coordinates workflows across data, applications, and AI so they behave like a system.

Takeaway: It’s not more orchestration. It’s the layer that makes everything already orchestrated actually behave predictably.

What a Control Plane Has to Get Right

Once you think in terms of a SOAP as the control plane, the question shifts pretty quickly from: “how do we run this workflow?” to “what does it take to keep this thing behaving under real conditions?”

In practice, there are a few things a control plane needs to get right if it’s going to hold up in production:

1. It actually has to run reliably

Not just once. Not just in a clean path. Across:

• cloud + onprem
• internal systems + external APIs
• workloads that don’t all behave the same way

AI makes this harder, not easier. Latency varies. Dependencies drift. Retries don’t always help. At some point, you realize the pipeline is only as reliable as the least predictable thing in it.

2. It has to understand what depends on what

This is the one most teams feel immediately. Something upstream is delayed, and you don’t find out until something downstream fails—or worse, runs with bad data.

Without system-level awareness, you’re always reacting. With it, you can actually see what’s at risk, what’s impacted, and what needs attention now.

3. It has to explain what’s going on

This is where things usually fall back to people. Someone knows how the workflow works, why it fails in weird ways, and what “normal” looks like. And everyone else is stuck asking them.

A control plane starts to pull that knowledge into the system itself:

• what this workflow does
• what changed
• what likely caused the issue

Not magic. Just enough context to stop everything from being a guessing game.

Takeaway: You’re no longer just running workflows. You’re running a system where behavior is visible, dependencies are understood, and issues are explainable. That’s what lets AI pipelines move from “it works” to something you can actually rely on.

What This Looks Like When It Actually Works

This is where the control plane idea stops being conceptual and starts showing up in real workflows.

1. When a “quick change” isn’t a scramble anymore

You get the request: “Can we refresh this dashboard with updated projections today?”

Without a control plane, that usually turns into a scramble—figuring out which pipelines are involved, coordinating across a few teams, manually triggering jobs, and then watching closely to see what breaks.

With a control plane, that same request is already understood as a workflow. The dependencies are mapped, the execution path is known, and the change can be applied in one place without chasing it across tools.

The difference isn’t just speed. It’s that the work becomes predictable and repeatable instead of reactive.

2. When AI actually makes it to production

Moving revenue forecasting models, fraud analysis pipelines, or supply chain optimization workflows from proof-of-concept to operational requires enterprise-grade discipline: governed data ingestion, controlled model execution, managed LLM invocation.

With a control plane, ingestion, transformation, inference, and downstream updates are all coordinated, observable, and governed the same way. At that point, moving to production stops feeling like starting over.

3. When governance isn’t a periodic fire drill

In most environments, workflow sprawl builds up quietly over time. Pipelines stick around long after they’re needed, dependencies overlap, and no one really has a clear view of what’s still in use. You don’t notice it until something breaks, performance slips, or there’s an audit coming up.

Without a control plane, governance is something you piece together after the fact. With one, the system itself starts to surface what’s changed, what’s no longer used, and where things are drifting. Governance becomes continuous instead of reactive.

Why the Lack of a Control Plane Feels Worse With AI

This isn’t a new problem. The gaps in how workflows are coordinated have always been there. AI just makes them obvious.

You now have more steps, more variability, more external dependencies (LLMs, APIs), and less predictable behavior. So the same coordination gaps that were manageable before start to show up everywhere.

Without a Control Plane

No shared context

• Each part runs its piece
• Dependencies are implicit
• Failures are discovered late
• People connect the dots manually

With a Control Plane (SOAP)

• One layer coordinates execution across everything
• Dependencies are explicit and visible
• Failures are understood in context
• Impact is clear before it spreads

Where SOAP Changes Day-to-Day Work

This is where it gets real.

• Instead of debugging across tools, you can actually see the workflow end to end.
• Instead of isolated failures, you get context about what those failures affect.
• Instead of relying on “who knows this pipeline,” the system carries that understanding.

With a SOAP, AI workloads stop being special cases and start behaving like everything else you run in production—the same way mature teams handle automation and orchestration across the rest of the stack.

Where to Start (Without Turning This Into a Rewrite)

You don’t need to replatform everything. You need to expose where you don’t have control.

1. Start with one pipeline that matters

Not a clean one. A real one. Map what actually happens: where data comes from, what it triggers, and what breaks if something is late. This is where hidden dependencies show up.

2. Count how many “control planes” you actually have

Most teams have multiple orchestration tools, scripts filling gaps, and people connecting the dots. Everything is orchestrated. Nothing is coordinated.

3. Make the system visible before you automate it

You should be able to answer, in one place: what does this workflow actually do, what depends on it, and what happens if it fails or drifts. If you can’t answer those, automation just makes troubleshooting harder.

4. Treat AI workloads like real workloads

This is where things quietly break. AI steps often have different retry behavior, weaker monitoring, and less consistent control. That works in testing. It doesn’t in production. Treat them like everything else: observable, governed, and part of the same system—which is increasingly what agentic orchestration is being built to handle.

5. Don’t try to fix everything at once

If one pipeline becomes visible, predictable and understandable, that’s already meaningful progress. From there, it scales.

What You’re Actually Building Toward

Not a new tool. Not a perfect architecture. Just this: a single layer that understands how your workflows behave and keeps them from drifting.

Once you have that, automation gets easier, failures are less surprising, and scaling doesn’t multiply chaos.

To Sum Up: The Shift That Actually Matters

AI isn’t a modeling problem anymore. It’s an operations problem: can you run complex, cross-system workflows reliably under real conditions? That’s the same shift driving teams to operationalize data and AI projects through orchestration.

If this feels familiar

If your current setup works, but only with careful coordination, tribal knowledge, and a few “don’t touch that” pipelines, you’re not behind. You’re just missing the layer that turns all of it into a system you can actually control. That’s the role SOAP is starting to play.

If you’re trying to move from “we got it working” to “we can run this reliably, every day”—here’s a practical guide to turning complex workflows into AI-powered outcomes: Orchestration: The Missing Layer in Enterprise AI.

This guide goes deeper into what’s missing when it comes to operationalizing AI—what it actually looks like in production, why it shows up so consistently, and how teams are starting to close the gap with a real control plane.

As digital certificate lifetimes drop to 47 days, automation becomes essential to maintain availability, security, and compliance. BMC AMI Digital Certificate Manager extends automated certificate lifecycle management to the mainframe, enabling standardization across the enterprise using your current CLM vendor.

Digital certificates are the connective tissue of the enterprise environment, enabling systems, workloads, applications, and APIs to verify each other and communicate securely. When a certificate fails due to expiration or error, the impact on service availability and security can be immediate and severe. And with regulators driving certificate lifetimes down to as little as 47 days by 2029, organizations face a sharp increase in both operational and compliance risk. That makes digital certificate management a top priority for BMC customers.

By enabling organizations to discover, track, and renew certificates across the infrastructure, digital certificate management prevents the outages and security gaps that can result from expired, misconfigured, or otherwise compromised certificates. This task has grown more difficult in recent years, and even greater challenges are on the horizon. But BMC has a solution.

Why digital certificate management is becoming an urgent challenge

Traditionally, many organizations have managed mainframe certificates through manual processes centered on spreadsheets and tribal knowledge. In recent years, the growing number of system identities relying on these certificates has pushed these methods to the breaking point. Now, regulatory changes have made them completely unsustainable.

To reduce the exposure that can result from a compromised certificate, the CA/Browser Forum has announced aggressive reductions in TLS certificate lifetimes. Until this month, companies were allowed a relatively manageable 398-day renewal cycle. Now that window has been nearly cut in half to 200 days. Next March, it will shrink once again to 100 days, and by March 2029, TLS certificates will be good for only 47 days. Each of these reductions effectively multiplies the certificate management workload for mainframe security teams, and with it, the chance of manual errors, expirations, and system outages.

This isn’t a future problem. The regulatory deadlines are fixed, the timelines are non-negotiable, and their impact is inevitable. That’s why I’m excited to announce BMC AMI Digital Certificate Manager (DCM)—a new solution that fundamentally changes certificate management on the mainframe.

How to extend enterprise digital certificate management to the mainframe

Most enterprises already invest in Certificate Lifecycle Management (CLM) platforms for their distributed and cloud environments. These platforms haven’t been able reach the mainframe, however, leaving z/OS as a manual island in an otherwise automated estate. Now BMC is filling that gap with the only solution enabling digital certificate management platforms to extend automation to the mainframe as part of a consistent enterprise strategy.

Proven in operational environments for over five years, DCM provides a unified integration layer to connect Venafi and Keyfactor digital certificate management tools to mainframe ESMs including RACF, ACF2, and Top Secret. With DCM, you can standardize on one BMC solution for your mainframe while supporting whichever certificate vendors your organization already uses, no rip-and-replace required.

End-to-end automated certificate operations

DCM extends your organization’s CLM to automate the entire mainframe certificate lifecycle, from issuance and renewal to replacement and rollback. The impact is immediate and measurable:

• Dramatic effort reduction: Mainframe certificate implementations that previously took up to three hours of manual work are now fully automated.
• Eliminated outage risk: Expired or mismanaged certificates are a major cause of preventable mainframe outages. DCM’s scheduled renewals and built-in rollback ensure continuous availability without late-night firefighting.
• Reduced dependency on scarce skills: Mainframe security expertise is increasingly hard to find. DCM removes the need for skilled personnel to manually execute certificate commands across RACF, ACF2, or Top Secret, freeing them for higher-value work.
• Complete audit visibility: Every action is logged with full detail, including which commands were issued, which ESM responses were received, who authorized the change, and when.

Real-world impact at a major financial institution

One of the world’s largest financial institutions evaluated DCM against its current, pre-automation state. With certificate volumes growing over 30 percent year over year, a small core team currently handles digital certificate management manually across many application owners and faces an increasing risk of outages, audit failures, and security gaps.

The firm projected the five-year value of deploying DCM as $8.6 million, driven by manual effort reduction and avoided headcount ($3.6M), eliminated application outages ($2.2M), compliance and audit risk reduction ($1.4M), operational efficiency gains ($0.8M), and future-proofing against accelerating certificate volumes ($0.6M). Beyond these measurable financial gains, the solution supports the institution’s broader strategic priorities around operational resilience and responsible growth.

Strengthening Zero Trust across the enterprise

Machine identity is foundational to Zero Trust: Every workload, process, and system must be authenticated. Working alongside BMC AMI Security, DCM becomes part of a comprehensive Zero Trust strategy for the mainframe, enabling continuous threat detection, automated response, and end-to-end protection across your most critical environment. Security teams gain the observability, policy enforcement, and confidence they need to report to the chief information security officer (CISO) and the board that the mainframe is truly protected.

Looking ahead

The certificate landscape continues to move toward shorter lifetimes, more frequent renewals, higher volumes, and tighter regulatory scrutiny. All of these trends will drive an exponential growth in manual digital certificate management workloads. By acting now, organizations can stay ahead of increasingly urgent certificate deadlines while preparing their infrastructure for continuous, automated certificate renewals.

BMC AMI Digital Certificate Manager is generally available. We invite you to learn more about how DCM can modernize certificate management across your mainframe environment—preserving your existing tools, eliminating manual effort, and building the operational resilience your business demands.

BMC is aware of recent industry discussion about the use of advanced AI techniques to identify software vulnerabilities, including initiatives such as Project Glasswing.

As part of normal security operations, BMC continuously monitors emerging research, threat intelligence, and industry developments related to software and supply chain security. These developments reflect an acceleration in how vulnerabilities may be identified across the industry.

BMC maintains a defense-in-depth security program and regularly evaluates opportunities to enhance controls and processes as technologies evolve. We engage with customers, partners, and the broader security community to remain aligned with industry best practices.

As new information becomes available, BMC will use its proactive notification process to help keep customers up to date.

To register for proactive notifications, please see the following BMC Support Central article:

https://docs.bmc.com/xwiki/bin/view/Standalone/BMC-Support-Central-User-Guide/supportcentraluserguide/Manage-Your-Support-Account/Favorite-Products-and-Alerts/