Here is a nice feature that has been high on the community requests list for some time.

It’s the ability to enter the actual result of a test step during manual test execution.

How it works

While you are running a manual test with test runner, you can now enter the actual result you encountered.

When you select pass or fail on the step you are presented with an Actual Result field to fill in. This is your opportunity to record what actually happened when you executed this step.

Now when you go to the test run you will see your Actual Results right along side the Expected Results.

Press enter or click to view image in full size

How to enable the Actual Result Feature

You can configure this setting per Test Plan. By default the feature is turned off. To turn it on go to Test Plan Settings in your test plan.

On the Test Plan settings window, select Test result settings. Here you can enable the Use “Actual result” field. Once enabled you also have two options it can be Optional and it can also be Required when an “Expected result” is defined.

The post Azure Test Plans: Include the “Actual Result” During Test Execution appeared first on Centrilogic.

TORONTO, ON, CANADA – May 12, 2026

Centrilogic, a global provider of IT transformation solutions, today announced that Mark Strater has joined the organization as Senior Vice President, Platforms and Infrastructure. 

Reporting to Centrilogic CEO Doug Tracy, Mark will lead the Platforms and Infrastructure business unit, with responsibility for advancing the strategy, delivery, and operational maturity of the foundational platforms that support customers’ growth and modernization initiatives. His mandate includes strengthening and evolving core infrastructure services across network & connectivity, data centers, public, private, and multi-cloud environments, as well as modern work solutions, ensuring these capabilities remain secure, resilient, and scalable as customer needs continue to evolve. 

Mark brings extensive experience building and operating global infrastructure and managed services organizations for mid-market and enterprise customers. Throughout his career, he has held senior leadership roles across leading technology and services firms including Ahead, Unisys, NTT Data, Dell, Perot Systems and more, where he was responsible for large-scale operations spanning cloud platforms, cybersecurity, data center services, networking, and service management. He is known for developing high-performing teams, driving operational excellence, and aligning technology platforms to measurable business outcomes. 

“Mark brings a rare combination of broad and deep infrastructure expertise and operational leadership,” said Doug Tracy, CEO of Centrilogic. “His experience leading complex, global services organizations will directly benefit our clients by strengthening the foundational platforms that enable scale, resilience, and innovation. This leadership is critical as our customers modernize their environments and accelerate their evolution toward AI‑enabled, data‑driven operating models.” 

Based in Frisco, Texas, Mark will focus on ensuring Centrilogic’s infrastructure capabilities continue to provide a strong, reliable foundation for customers as they modernize their environments, adopt advanced cloud architectures, and pursue digital transformation initiatives. 

 About Centrilogic 

Centrilogic is a global provider of IT transformation solutions that empower organizations to realize their full digital potential. Armed with capabilities that span the stack—including multicloud management, application innovation, data & analytics, AI, and IT advisory—Centrilogic delivers resilient, end-to-end digital solutions that help organizations transform technology platforms into business-driving assets. With regional headquarters in Canada, the United States, and India, Centrilogic supports innovative companies worldwide. 

The post Mark Strater Joins Centrilogic as SVP, Platforms and Infrastructure appeared first on Centrilogic.

This is the 4th and last post in a 4 part series. To read part 1 titled: Agentic AI Is Coming to the Enterprise — Are You Ready? visit https://www.centrilogic.com/agentic-ai-enterprise-readiness/

To read part 2, titled: Agentic AI is Coming to the Enterprise: – Threat Assessment, visit https://www.centrilogic.com/agentic-ai-enterprise-risks.

To read part 3, titled: Agentic AI Is Coming to the Enterprise – How to Design and Build Trustworthy Agentic AI, visit https://www.centrilogic.com/how-to-design-and-build-trustworthy-agentic-ai/

This is the fourth and final article in a four-part series about operations and security in the agentic AI world. It is intended for informational purposes only. Please engage an AI security professional before implementing agentic AI.

In the first three parts of this series, we covered why agentic AI represents a new category of enterprise risk, what the threat landscape looks like, and how to design systems with security built in from day one. Now comes the part most organizations underestimate.

Deployment is not the finish line. It is the starting gun.

Even a perfectly designed agentic AI is not “set it and forget it.” Autonomous systems evolve, adapt, and interact with dynamic environments that change constantly. That makes runtime security and continuous oversight not just important — they are core to the game.

In this article we will explore what needs to happen after the product launch, where the real business risks live, and where the most durable value is created.

1. Secure Deployment Isn’t Just a Launch Event

There is a natural tendency to treat go-live as the moment of completion and triumph. With agentic AI, it is better understood as the moment of ownership and accountability. You might comparing it to hiring a new employee. The operational environment your agent enters on day one will not be the same environment it operates in on day ninety. And it will grow and learn throughout its lifetime.

A safe launch establishes a secure baseline for ownership that can absorb change. That means:

Hardened environments — containers, virtual machines, and sandboxes that isolate agent activity from the broader system

Strict network controls — egress filtering, network segmentation, and private endpoints that limit what the agent can reach

Least-privilege identity assignments — the agent has exactly the access it needs, and nothing more

Proper secret management — no hardcoded credentials, ever, under any circumstances

Monitoring tools installed from day one — not added after something goes wrong

These aren’t just your typical code hygiene items. They are decisions that determine whether the inevitable security incident in your AI environment stays small or becomes a company-wide crisis.

2. Change Management Must Be Continuous

Agentic AI is a living system. It has a brain and ears, sometimes eyes, and a mouth. Models (the brains) are updated. Prompts are refined. Rules change. Integrations evolve. Every one of those changes is a potential security event if it isn’t properly governed.

That requires treating change management with the same discipline applied to the agent itself:

Versioning for models, prompts, rules, and configurations — so you always know what changed and when

Rollback plans for when new versions behave unexpectedly — tested in advance, not improvised after the fact

Security reviews before any new integration or functionality goes live

Routine audits of agent activity logs — not just after incidents, but as a standing practice

The analogy here is not software deployment. It is closer to employee performance management. You wouldn’t onboard a new employee, assign them broad responsibilities, and then never check in again. The same logic applies to an agent operating autonomously on your behalf. You MUST manage them actively and evaluate their performance, compliance, and work ethic. To that end, you must…

3. Monitor Behavior in Real Time

Runtime oversight is where agentic AI security earns its keep.

The goal isn’t to watch every action — that defeats the purpose of automation. The goal is to define what normal looks like and respond immediately when something deviates from it. Behavioral monitoring establishes the agent’s baseline and alerts when patterns shift. The signals worth watching include:

• Unexpected API calls or calls to systems outside the agents defined scope
• Sudden spikes in activity volume or frequency
• New categories of actions that weren’t part of the original operational profile
• Resource overconsumption — compute, memory, storage, or API quota
• Attempts to access data the agent has no business reason to touch

Intrusion detection needs to be modified to go a layer deeper. Scanning for known malicious AI prompt patterns and memory tampering signatures catches the threats that traditional security tools were never built to recognize.

Lastly, policy enforcement engines can be implemented to close the loop. Detection is only useful if it triggers action. The right tools don’t just log violations — they stop disallowed actions the moment they occur.

4. Make Audit and Accountability First-Class Citizens

With autonomous systems, accountability is a clear and present concern. AI agents cannot be trusted. It’s a simple truth. AI agents are naive and trustworthy themselves. They are easily duped by malicious threat actors. Audit is another mechanism through which the organization maintains trust with employees, customers, auditors, and regulators.

A serious audit posture for agentic AI includes:

Full logs of all agent actions — inputs, outputs, decisions, and the reasoning behind them

Monitoring dashboards that give executives and risk teams real-time visibility, not periodic reports

Regular reviews by AI governance committees, not just the teams that built the system

Clear ownership of AI related outcomes — someone must be accountable when an agent acts, just as someone is accountable when an employee acts

Forensic readiness — the ability to reconstruct exactly what happened within an agent workflow, in time-based sequence, should a forensic investigation be required

When accountability is visible to the entire organization, something important happens. Confidence in the agent’s role increases. Business owners engage more thoughtfully. Teams take AI accountability seriously because they know it’s real.

Remember that accountability is not a constraint on agentic AI. It is what makes agentic AI sustainable for the business.

5. Treat runtime Security as an Ongoing Partnership

One of the most common failure modes in agentic AI governance is treating it as an engineering problem. It isn’t. Engineering builds the controls. Governance keeps them working.

Runtime security requires active participation from:

• Security — threat intelligence, incident response, and ongoing risk assessment
• IT operations — infrastructure health, change control, and environment stability
• AI/ML teams — model behavior, performance drift, and prompt management
• Risk & compliance — regulatory alignment, audit readiness, and policy enforcement
• Business owners — objective alignment, outcome review, and the authority to say when something isn’t working

No single team can do this alone. And no organization that assigns agentic AI governance entirely to engineering should be surprised when business alignment with AI breaks down.

Just like human resource management, governance of agentic AI is organizational. That distinction matters more than most leaders realize until they experience a negative outcome.

The Bottom Line

Agentic AI is the future of enterprise automation. Not someday — now. But that future only delivers on its promise if the systems are deployed with discipline, monitored with rigor, and held to the same standards of accountability we apply to the people they work alongside.

Organizations that build these practices early will find that agentic AI becomes a genuine workforce multiplier. Organizations that skip them will find that the first serious incident costs far more than the governance would have.

This is the moment to build the practices, the policies, and the organizational mindset that will define the next decade of intelligent automation. Not after the first deployment. Not after the first audit finding. Now. You’re not just deploying software anymore. You’re deploying virtual employees. Treat it with the same rigor and the same expectations.

The post Agentic AI Is Coming to the Enterprise – Securing Agentic AI in the Real World — Monitoring, Auditing & Managing Change appeared first on Centrilogic.

TORONTO, ON, CANADA – April 8, 2026 – Centrilogic, a global provider of IT transformation solutions, today announced it has earned the Data Analytics on Microsoft Azure Specialization, further validating the company’s expertise in planning, designing, and delivering advanced analytics on Microsoft Azure.  

The Data Analytics on Microsoft Azure Specialization recognizes partners that demonstrate extensive capabilities in delivering end-to-end data analytics solutions, from data strategy and architecture design through implementation, optimization, and ongoing support.  

To earn this specialization, Centrilogic met Microsoft’s highest standards for analytics service delivery, governance, security, and support. Centrilogic also demonstrated proven customer success, strong technical capabilities, and mature delivery practices across Azure data and analytics services, including modern data platforms, advanced analytics, and AI-driven insights.  

This recognition also highlights Centrilogic’s ability to help mid-market and enterprise customers maximize the value of their data assets and build secure, scalable, enterprise-grade analytics platforms that enable transformative insights and better business decision-making.  

“Earning the Data Analytics on Microsoft Azure Specialization underscores our focus on helping organizations build strong, trusted data foundations that enable better decision-making at scale,” said Doug Tracy, CEO of Centrilogic. “As data and analytics become central to AI adoption and enterprise strategy, organizations need partners who can design, govern, and operationalize analytics platforms that deliver real business insights and benefits. This recognition reinforces our ability to help customers move from data complexity to clarity with confidence.”  

Centrilogic and Microsoft have built a trusted partnership spanning more than 15 years, working together to help midmarket and enterprise organizations modernize data platforms, accelerate analytics adoption, and enable AI-driven decision-making across the Microsoft cloud ecosystem. Backed by a team of senior Microsoft-certified experts, Centrilogic delivers comprehensive solutions across application modernization, cloud engineering, data & AI, security, DevOps, and managed services.  

About Centrilogic:   

Centrilogic is a global provider of IT transformation solutions that empower organizations to realize their full digital potential. Armed with capabilities that span the stack – including multi-cloud management, application innovation, data & AI, and IT advisory – Centrilogic delivers resilient end-to-end digital solutions that help companies reshape the role of their technology platforms as business-driving assets. With regional headquarters in Canada, USA, and India, Centrilogic delivers solutions to innovative companies worldwide. For more information, visit www.centrilogic.com.   

The post Centrilogic Achieves the Data Analytics on Microsoft Azure Specialization  appeared first on Centrilogic.

How Do I Run AI Workloads When My Regulator Says the Data Can’t Leave the Country?

I often find myself in conversations with Canadian executives who are wrestling with the same question: “We want to deploy AI. Our regulator says the data stays in Canada. Now what?”

It’s a fair question. And it’s one that most of the public conversation around AI is failing to answer clearly.

The vendor keynotes talk about transformation. The compliance team talks about risk. The board wants both. The people in the middle, the Architects, CIOs, VPs of IT, are left trying to reconcile two mandates that feel like they’re on a collision course.

I lead an architecture team that designs and delivers cloud and AI environments for regulated Canadian organizations. We’re not theorizing about what’s possible. We’re building what works today, within the constraints that actually exist. This is the ground-level view.

“Data Can’t Leave the Country” Is More Complicated Than It Sounds

The first thing executives need to understand is that “Canadian data residency” isn’t a single rule. It’s a stack of overlapping obligations that vary by province, sector, and data classification.

At the federal level, PIPEDA doesn’t actually mandate that data stay in Canada. It requires organizations to inform individuals about cross-border transfers and obtain meaningful consent. That’s an important distinction, but it’s also just the baseline.

The real teeth come from the provinces and sector regulators. Quebec’s Law 25 imposes the strictest regime in the country: any transfer of personal information outside the province requires a privacy impact assessment, and the destination jurisdiction must offer protection “essentially equivalent” to Quebec law. The penalties, up to $10 million or 2% of worldwide revenue, are not theoretical. Ontario’s PHIPA is widely believed to mandate that personal health information stay in Canada, but the reality is more nuanced. PHIPA restricts unconsented disclosures to independent third parties outside the province, not the hosting of data by a cloud provider acting as an agent under contract. A hospital using Azure to run an AI diagnostic model isn’t “disclosing” data to Microsoft in the PHIPA sense, provided the right contractual safeguards are in place. The distinction matters because it opens architectural options that many healthcare organizations assume are off the table. Alberta’s PIPA adds yet another layer.

Then there are the sector regulators. OSFI’s Guideline B-13 (Technology and Cyber Risk Management) is often cited as requiring in-country processing, but it’s actually a principles-based risk management framework, not a geographic embargo. It requires rigorous oversight of third-party vendors, robust incident reporting, and comprehensive risk documentation. Many financial institutions choose to localize data processing because it simplifies their risk posture, but B-13 itself doesn’t forbid foreign processing if the controls are in place. What it does mean is that if you process data outside Canada, you own the burden of proving you’ve managed every associated risk.

Separately, OSFI finalized the updated Guideline E-23 (Model Risk Management) in late 2025, with a mandatory effective date of May 1, 2027. This is the one that changes the game for AI. E-23 now explicitly covers AI and machine learning systems, requiring enterprise-wide model identification, risk assessment, deployment controls, continuous monitoring, and formal decommissioning processes. If you’re in financial services, your AI models will need the same governance rigor as your credit risk models. This isn’t guidance. It’s regulatory expectation with a hard deadline.

The point is: when a regulator says “the data stays here,” the specific meaning depends entirely on who your regulator is, what province you’re in, and what kind of data you’re handling. Most organizations underestimate this complexity until they’re already deep into an AI initiative.

PBMM: The Standard That Gates Public Sector, and Increasingly Everything Else

If you work with the Canadian federal government, you already know Protected B, Medium Integrity, Medium Availability (PBMM). It’s the cloud security standard defined in ITSG-33 and evolved into the CCCS Medium Cloud Profile. It’s the bar your cloud environment has to clear to handle non-classified government information.

What’s changed is that PBMM is no longer just a public sector concern. We see it referenced in provincial procurement, in RFPs from regulated private sector organizations, and as a proxy standard for “serious about security” in industries that don’t have their own cloud certification framework.

The major cloud providers have all invested in PBMM assessments. Azure was one of the first to qualify. AWS reports 162 services assessed against CCCS Medium requirements as of late 2025. Google Cloud is approved for Protected B Medium and High Value Asset workloads. IBM maintains PBMM in their Toronto and Montreal facilities.

But here’s the gap that matters: PBMM certification for AI-specific services (Azure OpenAI, Cognitive Services, the inference endpoints you actually need) is not explicitly published in the same way that general IaaS and PaaS services are. General cloud PBMM is not the same as AI service PBMM. This distinction is where deals stall, and projects get delayed. If you’re building an AI workload for a regulated environment, you need to understand exactly which services have been assessed and which are running on assumption.

What You Can Actually Run Today

Let me be direct about the current state, because I think the market needs more honesty here and less aspiration.

Azure OpenAI offers models in Canada Central and Canada East, but model availability varies significantly by deployment type. Established models like GPT-4 and GPT-4o support standard regional deployments with strict data residency: both inference and data processing happen exclusively within Canadian data centres. However, newer frontier models (the GPT-4.1 series, advanced reasoning models like o1 and o3) are currently unavailable for standard regional deployment in Canada Central. To access these, architects are pushed toward “Global Standard” or “Data Zone” deployment types, which dynamically route inference across Azure’s global infrastructure, fundamentally breaking strict data residency. This is a critical distinction: you can run production AI in-region today, but the most capable models may require you to choose between cognitive performance and geographic isolation.

AWS Bedrock offers foundation model access from ca-central-1 (Toronto) and ca-west-1 (Calgary), including Anthropic’s Claude models. But there’s a critical nuance: AWS achieves this through cross-region inference. Your data at rest (logs, knowledge bases, stored configurations) stays in Canada, but the inference processing itself may route to US regions. For workloads where the regulator cares about where compute happens, not just where data sits, this distinction matters. You need to understand whether your compliance framework draws the line at data residency or processing residency.

Anthropic’s Claude API (direct, not through a cloud provider) currently processes all data in the United States. There is no Canadian data residency option. Anthropic has introduced EU data residency for API customers, which suggests regional expansion is on the roadmap, but nothing is announced for Canada. For organizations that need Claude’s capabilities within Canadian borders today, the path runs through Bedrock, with the cross-region inference caveat above.

Google Vertex AI offers Claude and Gemini models in the Toronto region, with regional endpoints that provide guaranteed data routing through specific geographic regions. This adds another option, though at a 10% pricing premium over global endpoints.

The honest summary: you can run production AI inference in Canada today, with real data residency guarantees, if you choose the right platform, the right models, and the right deployment configuration. But the most capable frontier models often require global routing that breaks strict residency, and the managed orchestration services are either deprecated or unavailable in-country. The gap is narrowing fast, but if you’re making architecture decisions right now, make them based on what’s certified and available, not what’s on a roadmap.

The Architecture Decisions That Actually Matter

These are the conversations that separate a successful sovereign AI deployment from one that stalls in procurement review.

Region selection is a governance decision, not a performance decision. Lock Canada Central as your AI compute region. Document the rationale. Make the decision auditable. This sounds obvious, but I’ve seen organizations leave region selection to a developer’s default configuration and then scramble to explain it to an auditor six months later.

Classify your data before you select your models. Know what’s Protected B, what’s sensitive personal information, what’s proprietary but not regulated, and what’s public. Then map each classification to the services that are certified to handle it. Most organizations want to start with the model and work backward to the data. That’s exactly the wrong order for regulated environments.

Understand that “available in Canada” means different things on different platforms. Azure OpenAI in Canada Central runs inference in-region for supported models, but frontier models may require Global routing that breaks residency guarantees. Bedrock cross-region inference from ca-central-1 keeps data at rest in Canada but may process inference in the US. Anthropic’s direct API runs entirely in the US. These are not equivalent from a compliance perspective, even though all three give you access to powerful models. Your architecture needs to reflect the actual data flow, not the marketing summary.

Stay current on platform deprecations. If you’ve been planning agent-style orchestration around Azure OpenAI’s Assistants API, stop. Microsoft has officially deprecated the Assistants API, with complete retirement scheduled for August 26, 2026. It has been replaced by the Microsoft Foundry Agents Service, a modernized framework with stronger observability, version control, and enterprise governance. Any organization building custom middleware while waiting for Assistants to land in Canada is investing in a dead end. Architects should evaluate Foundry Agents now and plan migration paths for any existing Assistants-based work. More broadly, this is a reminder that the AI platform landscape is moving fast enough to invalidate architectural assumptions within months. Build modularly, stay close to the deprecation notices, and don’t bet your architecture on a single service remaining stable.

Contractual data residency is not the same as technical data residency. Azure’s contractual commitments around Canadian data processing are strong. But your architecture has to enforce them. Private Endpoints, Azure Policy definitions that deny non-Canadian resource creation, network security groups, diagnostic settings that keep logs in-region: these are the controls your auditor will actually ask about. A contract tells your regulator you intend to keep data in Canada. Your technical controls prove you did.

Treat model risk management as a first-class governance discipline. This one is specifically for financial services today, but it’s heading everywhere. OSFI E-23 takes full effect May 1, 2027, and it covers AI/ML explicitly. Model identification, risk assessment, deployment controls, performance monitoring, bias testing, explainability, and formal decommissioning are all in scope. Build these into your AI platform from day one. Retrofitting governance to satisfy an OSFI audit after the fact will be far more expensive and disruptive than doing it right up front.

The underlying principle: sovereign AI is not a product you buy. It’s an architecture you design. The decisions that matter most are the unglamorous ones: region locks, data classification, policy enforcement, model governance.

The CLOUD Act – Elephant in the Room

I’d be doing a disservice if I didn’t address this directly, because every informed client raises it and too many advisors dodge it.

The U.S. CLOUD Act gives American authorities the legal right to compel U.S.-headquartered companies to produce data in their custody, regardless of where that data is physically stored. Microsoft, AWS, Google, and Anthropic are all U.S.-headquartered. Your data can be sitting in a Toronto data centre, running on Azure, with a Canadian data residency contract, and the U.S. government can still, in principle, issue a lawful demand for it.

Microsoft has responded with a five-point Digital Sovereignty Plan: a Threat Intelligence Hub in Ottawa, expanded confidential computing capabilities, enhanced data residency commitments, sovereign landing zone architectures, and contractual protections designed to keep Canadian data under Canadian legal authority. These are meaningful steps. AWS and Google have made similar commitments around data sovereignty, though with different implementation approaches.

Here’s what honest advisors tell their clients: the combination of Canadian data residency, encryption at rest and in transit, customer-managed keys, access controls, and contractual commitments significantly reduces the practical risk. For the vast majority of regulated workloads, this combination meets the bar that Canadian regulators are setting. For a narrow set of the highest-sensitivity workloads (think national security, certain government classified environments), it may not, and those organizations may need sovereign cloud options or on-premises deployments.

The pragmatic position: don’t pretend the CLOUD Act doesn’t exist. Don’t pretend it blocks everything, either. Understand where your data sits on the sensitivity spectrum and architect to the actual risk, not the headline.

What the Next 12 Months Look Like

The investment wave is real. Microsoft’s $7.5 billion. The federal government’s $925 million. The AI Compute Challenge calling for 100+ megawatt sovereign data centres. The University of Toronto receiving $42.5 million for AI compute infrastructure. This isn’t speculative. It’s funded and in motion.

But there are things the money doesn’t solve yet. Canada still has no comprehensive AI legislation. Bill C-27 and AIDA died when Parliament dissolved in 2025, and while a successor is expected, the timing is uncertain. In the meantime, sector regulators (OSFI, Health Canada, Transport Canada) are filling the gap with guidance that has practical regulatory weight even without a new law.

The AI platform landscape is also converging on Canada. Anthropic is expanding its regional data residency options (EU is live, other regions are expected to follow). AWS is broadening Bedrock’s in-region capabilities. Microsoft is pouring infrastructure dollars into Canadian capacity that comes online in H2 2026. Cohere, a Canadian-founded AI company, has models available on Azure, adding a sovereign-origin option to the platform.

What this means for executives making decisions today: the infrastructure is coming, the regulatory framework is converging, and the service gaps are closing. But you should not architect for next year’s availability. Build on what’s certified and available now. Design your governance framework so it can absorb new services and new regulations as they arrive. The organizations moving now, with proper controls, will have 12 to 18 months of operational learning and institutional knowledge that their competitors won’t.

Waiting for perfect regulatory clarity before deploying AI in a regulated Canadian environment means waiting indefinitely. The organizations that will lead didn’t wait for perfection. They moved with governance.

Reframing the Question

The question I started with (“How do I run AI workloads when my regulator says the data can’t leave the country?”) is actually the wrong question, or at least an incomplete one.

The better question is: How do I architect AI workloads that satisfy my regulator, my board, and my users, simultaneously?

The answer isn’t a single product or a single certification. It’s an architecture designed with intention: the right region, the right data classifications, the right technical controls, the right governance model, and an honest assessment of what’s certified today versus what’s on someone’s roadmap.

The infrastructure investment is happening. The regulatory frameworks are converging. The AI services are landing in Canadian regions. The window for competitive advantage is open right now, for the organizations willing to build thoughtfully rather than wait for someone else to make it easy.

I’d like to hear what you’re seeing in your own environments. If you’re navigating sovereign AI in a regulated Canadian industry, what’s working? Where are you stuck? The more practitioners share what they’re learning, the faster this market matures for everyone.

The post How Do I Run AI Workloads When My Regulator Says the Data Can’t Leave the Country? appeared first on Centrilogic.

TORONTO, ON, CANADA – March 31, 2026 – Centrilogic, a global provider of IT transformation solutions, today announced it has earned the Agentic DevOps with Microsoft Azure and GitHub Specialization, validating the company’s ability to help mid-market and enterprise organizations establish secure, modern software development practices by applying DevOps principles and using GitHub and Azure solutions.

This specialization recognizes Microsoft partners that demonstrate deep expertise in delivering end‑to‑end agentic DevOps capabilities, spanning initial assessment and solution design through pilot, implementation, and post‑implementation support. Achieving this designation confirms that Centrilogic has adopted robust, repeatable processes that support customer success across all phases of agentic DevOps.

Earning this specialization places Centrilogic among a select group of Microsoft partners that meet Microsoft’s stringent technical, performance, and audit requirements. It reflects proven customer success, strong technical capabilities, and mature delivery practices aligned with Microsoft’s Azure DevOps and GitHub solutions.

“Achieving the Agentic DevOps with Microsoft Azure and GitHub Specialization reflects our continued investment in modern engineering practices and our commitment to helping customers build, deploy, and operate software securely and at scale,” said Doug Tracy, CEO of Centrilogic. “As organizations look to adopt agentic and AI‑driven development models, DevOps discipline becomes even more critical. This recognition reinforces our ability to guide customers through that journey with confidence.”

Centrilogic and Microsoft have built a trusted partnership spanning more than 15 years, working together to help mid‑market and enterprise organizations modernize applications, improve developer productivity, and accelerate innovation across the Microsoft cloud ecosystem. Backed by a team of senior Microsoft‑certified experts, Centrilogic delivers comprehensive solutions across application modernization, cloud engineering, DevOps, data & AI, security, and managed services.

About Centrilogic:

Centrilogic is a global provider of IT transformation solutions that empower organizations to realize their full digital potential. Armed with capabilities that span the stack – including multi-cloud management, application innovation, data & AI, and IT advisory – Centrilogic delivers resilient end-to-end digital solutions that help companies reshape the role of their technology platforms as business-driving assets. With regional headquarters in Canada, USA, and India, Centrilogic delivers solutions to innovative companies worldwide. For more information, visit www.centrilogic.com.

The post Centrilogic Achieves Agentic DevOps with Microsoft Azure and GitHub Specialization appeared first on Centrilogic.

This is the 3rd post in a 4 part series. To read part 1 titled: Agentic AI Is Coming to the Enterprise — Are You Ready? visit https://www.centrilogic.com/agentic-ai-enterprise-readiness/

To read part 2, titled: Agentic AI is Coming to the Enterprise: – Threat Assessment, visit https://www.centrilogic.com/agentic-ai-enterprise-risks.

This is the third in a four-part series about operations and security in the agentic AI world. It is intended for informational purposes only. Please engage an AI security professional before implementing agentic AI.

In the first two parts of this series, we explored why agentic AI represents a fundamentally new category of enterprise risk, and what the threat landscape actually looks like for leaders who are preparing to deploy autonomous systems. Now it’s time to get practical.

The good news: trustworthy agentic AI is absolutely achievable. The catch: you can’t bolt security on after the fact. With agentic systems, safety must be designed in from the very beginning — before the first line of code is written.

Here is a practical blueprint for doing exactly that.

1. Start With “Security by Design”

Most technology initiatives begin with capability. Agentic AI requires flipping that script. Security isn’t a feature you add at the end. It’s the foundation everything else is built on. Three principles should guide every agentic architecture from day one:

• Defense-in-depth. Layer your controls so that a single failure doesn’t compromise the entire system.
• Least privilege. Give agents the minimum permissions needed to do their job — nothing more.
• Zero trust. Validate every action an agent takes, even within your own environment. Assume nothing is inherently safe.

These aren’t abstract ideals. They are practical design decisions that prevent oversights from becoming liabilities.

2. Threat Model the Agent in Business Language

Threat modeling sounds like an IT exercise. It doesn’t have to be. Business leaders can and should participate in this process. The questions are straightforward:

• What could go wrong with this agent? ·
• Who could misuse it — internally or externally?
• What is the worst-case scenario for this workflow?
• What data might be exposed, altered, or corrupted?

Once you’ve answered those questions, translate the risks into concrete design requirements:

• Should certain actions require human approval before the agent proceeds?
• Should the agent be sandboxed from sensitive systems?
• What should never happen under any circumstances?
• What must be logged for auditing and accountability?

This conversation produces a practical security roadmap for the engineering team and keeps business intent at the center of the design.

3. Define Agency vs. Autonomy

This is one of the most powerful mental models for enterprise AI adoption, and one of the least understood.

Agency is what the agent is allowed to do — reading data, writing records, sending communications, triggering workflows.

Autonomy is when it’s allowed to act without human oversight — never, sometimes, always, or only within specific conditions.

These two dimensions can be mixed and matched deliberately:

• High agency, low autonomy — the agent can do a lot, but a human approves every significant action.
• Low agency, high autonomy — the agent acts freely, but within a very narrow scope.
• High agency, high autonomy — powerful, but rare and high-risk. Reserved for mature, well-monitored systems.
• Low agency, low autonomy — common in pilots. Safe starting point for most organizations.

Defining this operational envelope gives leaders precise control over what an agent can do and when. It also makes the conversation between business and technical teams dramatically more productive.

4. Build in Observability and Control

Agentic AI should never be a black box. Your architecture needs to answer these questions at any point in time:

• Why did the agent take that action?
• What sequence of decisions led to this outcome?
• Who or what authorized it?

That means building in:

Rationale logging — a record of why the agent acted, not just what it did.

Traceability— a full audit trail of the decision chain.

Circuit breakers — automated mechanisms that halt agent activity when behavior falls outside acceptable boundaries.

Human review workflows — escalation paths for actions with significant business, financial, or regulatory impact.

These aren’t overhead. They are the mechanisms that make agentic AI trustworthy to executives, auditors, regulators, and the customers you serve.

5. Align With Industry Frameworks

There are several established frameworks that support responsible agentic AI design. Use them as tools, not textbooks:

NIST AI RMF – excellent for governance structure and risk context mapping.

ISO/IEC 42001 – provides an organizational framework for AI management systems.

CSA MAESTRO – purpose-built for threat modeling AI and multi-agent systems.

OWASP LLM Guidelines – critical for addressing prompt injection, output handling, and integration security.

Together, these guides give your organization a holistic, defensible approach to AI Threat mitigation that will hold up to audit and legal scrutiny both internally and externally.

6. Produce Deliverables Your Organization Can Actually Use

By the end of the design phase, your team should be able to hand the following to engineering, operations, legal, and risk:

• System architecture diagrams with security components clearly identified
• A threat model with specific, actionable mitigations
• Defined agency and autonomy levels for each agent
• An accountability model that answers “who owns this agent’s actions?”
• Logging and audit requirements
• Guardrail policies and decision thresholds
• Clear boundaries on what the agent is allowed and not allowed to do

This isn’t documentation for its own sake. It’s the difference between an agentic system that scales confidently and one that generates a crisis the moment something unexpected happens.

The Takeaway

Enterprises that design agentic AI correctly will be positioned to adopt the technology safely, quickly, and with a meaningful competitive advantage. Those who rush in without a blueprint risk failures that are operational, financial, and reputational — and increasingly public.

The design phase is where trust is either built or forfeited. It is worth the investment.

In the final article of this series, we will explore how to operate, monitor, and govern agentic AI in real time with practices that keep autonomous systems aligned, auditable, and effective long after they go live.

Remember, the easy part of agentic AI is building it. The hard part is making it a trustworthy tool for your business.

The post Agentic AI Is Coming to the Enterprise – How to Design and Build Trustworthy Agentic AI appeared first on Centrilogic.

Azure DevOps Love

New features and enhancements are coming to Azure DevOps all the time, and it makes me so happy.

Here are a few that just dropped this month. They are so new you may not see them in your instance of Azure DevOps yet, as they roll out gradually. Actually some of the images below are taken from release notes because the feature has not shown up in my Azure DevOps yet. 🙂

Azure Boards — Condensed card display.

I love this new feature. Adding information to the cards in on your Kanban board can be so useful. However it’s easy to get carried away and the card ends up very big.

A new toggle switch has been added called Collapse card fields. Highlighted in the image below, and turned off.

Click that button and all the extra info is hidden and you just see the work item with it’s ID and description.

Azure Repos — Auto-complete pull requests by default

I have always loved the auto-complete feature in Azure Repos. For those not familiar, you can create a PR and set it to auto-complete. Which means after all the checks have passed and it’s been approved by reviewers, the PR will be automatically closed and merged. No need for you to come back later and merge the PR.

Well now you can make this the default setting either for the whole project or for each Repo individually.

When this is enabled, every new PR will automatically have Set auto-complete turned on. When disabled, new PRs will start with Set auto-complete turned off, and authors can choose to enable it manually.

Azure Test Plans — Exploratory Testing

As you may have read in past posts, I love Azure Test Plans. I also love the Exploratory Testing tool. Microsoft recently updated the test run user interface, it was previously terrible and ignored for too long. It’s much better now, perhaps a post about that is required. Well the exploratory Test runs was also terrible, as it was just tucked away in with test runs.

As of this month it has it’s own place of honour in the main navigation bar under Test Plans.

The post New Features in Azure DevOps – March 2026 appeared first on Centrilogic.

This is the 2nd post in a 4 part series, to read part 1, visit: https://www.centrilogic.com/agentic-ai-enterprise-readiness.

Agentic AI is Coming to the Enterprise: Part 2 – Threat Assessment

The post Agentic AI is Coming to the Enterprise: Part 2 – Threat Assessment appeared first on Centrilogic.

To read part 2, titled: Agentic AI is Coming to the Enterprise: Part 2 – Threat Assessment, visit https://www.centrilogic.com/agentic-ai-enterprise-risks.

Agentic AI Is Coming to the Enterprise — Are You Ready?

This is the first in a four-part series about operations and security in the agentic AI world. It is intended for informational purposes only. Please engage an AI professional before implementing agentic AI.

In case you looked away for a moment, you might not have noticed that agentic AI is no longer a far off, futuristic concept. It’s here today, rapidly making its way into enterprises of all sizes. Unlike simpler, generative AI models that respond to a single prompt and then stop and wait for their next task, agentic AI systems can plan and execute multi‑step tasks, invoke external tools to do work, integrate seamlessly with other business systems, and most importantly, can act autonomously to reach a goal. As my colleague says, “Agentic AI doesn’t just tell you what to do — it actually does it.”

And from a security perspective, that shift changes everything.

AI Autonomy Creates Risk

Agentic AI introduces additional threats to the business that generative AI operational frameworks were not designed to address:

• Unauthorized operations: An agent with system access can perform actions directly — including harmful ones — if compromised or simply inadequately trained or constrained.
• Goal drift: Agents can creatively pursue perceived objectives in unintended ways and cause unintended, collateral damage.
• Adversarial manipulation: Malicious prompts or poisoned data can redirect agent to malicious behavior in the production environment.
• Integration exploitation: Because agents often interact directly with APIs, tools, and enterprise systems, they expand the organizational security attack surface.
• Memory poisoning: Persistent agent memory can become a vector for misinformation, bias, or manipulation.
• Accountability gaps: If an autonomous agent performs a harmful action, it may be unclear who is responsible and accountable for those acts.

Just like humans, the very autonomy that makes agentic AI so powerful also makes it vulnerable to attack and, without proper support and controls, potentially dangerous. The enterprise must treat AI as it treats any worker in the organization, and plan ahead for the potential vulnerabilities those workers may introduce.

Existing Security Frameworks Aren’t Enough

Standards like the NIST AI Risk Management Framework and ISO/IEC 42001 give broad guidance on managing AI risk. But they weren’t built for autonomous systems capable of initiating actions, chaining decisions, or using tools on their own.

Adopting agentic AI requires the enterprise to also adopt:

• New architectural safeguards that design security and integrity directly into agentic systems.
• New runtime monitoring approaches to catch and prevent errors and breaches proactively.
• New responsibility and accountability models that merge AI and human activities.
• New threat categories directly related to AI specific activities.
• New lifecycle controls to prevent the introduction of threats or vulnerabilities into change pipelines, which are much more dynamic in an AI environment.

The existing security frameworks at most organizations simply aren’t prepared to deploy agentic AI into the production environment, and the opportunity to have your business processes compromised is very real.

The Path Forward

While all this might sound daunting, there is no difference in deploying AI into your organization as there would be with any human or system based operational or decision support technology. There is a framework and set of steps to follow. At a high level. organizations that want to safely capture agentic AI’s benefits and beyond must:

• Understand the new threat landscape that agentic AI brings
• Architect and Design your autonomous AI systems with proper guardrails
• Shift from “model‑centric” to “agent‑centric” governance
• Build accountability, explainability, and oversight into every layer of the agentic system
• Treat agentic AI as a living system that evolves — and must be monitored and adjusted continuously

The agentic AI future is coming fast, and securing it properly could be the difference between a great success and a hasty, and costly retreat.

In the next article, we’ll explore the full threat landscape of agentic AI and break down the categories of risk executives must understand before deploying autonomous systems.

The post Agentic AI Is Coming to the Enterprise — Are You Ready? appeared first on Centrilogic.