IBM has been moving quickly on agentic AI, and Cognos Analytics is no exception. With Cognos Analytics 12.1.3, organizations can use new AI capabilities, source control, and automation features that can materially change how finance and BI teams create, manage, and govern analytics content.

That is a significant opportunity. It also changes the risk conversation. When AI can interact with Cognos, the question is no longer simply whether a person has access to a report. The more important questions are: What identity is the AI using? What is that identity authorized to do? How much of the environment can it affect? And if it makes a bad but authorized change, how quickly can you recover?

According to an April 2026 study by the Cloud Security Alliance and Token Security cited in our original analysis, 65 percent of organizations experienced a cybersecurity incident caused by an AI agent operating on their network in the prior year, and 53 percent found that an agent had exceeded its intended permissions. The lesson for Cognos teams is not to avoid AI. It is to design the controls before scaling the access.

Cognos Security Still Matters Under MCP

One important distinction needs to be clear: an AI agent connected to Cognos should not magically bypass Cognos authorization. Cognos determines what an authenticated user, application, or device is entitled to access and what actions it can perform. IBM also applies permissions and capabilities to content and functionality.

That is good news, but it does not make the risk disappear. It shifts the risk toward identity design and least privilege. If the identity used by the AI can only read approved Finance Reporting content, the AI should be constrained by that authorization. If the identity can modify content, manage security, change configuration, or perform administrative functions, the potential blast radius is much larger.

This is why the wrong question is, “Is MCP secure?” The better question is, “What have we authorized this AI identity to do in our Cognos environment?”

Running a Report Is Not the Same as Administering Cognos

IBM describes the Cognos MCP server as exposing tools across categories that include reporting, administration, security, and configuration. Those categories should not be treated as if they carry the same risk.

Giving an AI assistant permission to search for an approved finance report and run it is one security profile. Giving an AI-connected identity access to users, groups, roles, permissions, connections, deployments, configuration, or server administration is an entirely different profile.

For most organizations, “AI access to Cognos” should therefore not mean one universal MCP identity with broad privileges. The safer operating model is to create distinct identities and access tiers based on the work the agent is expected to perform.

A Practical Three-Tier Cognos MCP Access Model

A useful starting point is to separate AI access into three tiers. This is a Lodestar operating model, not an IBM-prescribed architecture, and it should be adapted to each organization’s security, governance, and regulatory requirements.

For many organizations, the safest rollout is to start with Tier 1, validate the use cases and controls, and expand privileges only when there is a documented business need. Administrative capabilities deserve an entirely different approval, monitoring, and recovery profile from report consumption.

Least Privilege Reduces the Risk. Recovery Reduces the Consequences.

Permission design is the first control. It limits what the AI can touch. But least privilege does not protect you from every problem. An AI agent can still make a bad change that is fully within its authorized permissions.

That distinction matters. Security controls are preventative. Recovery controls determine how painful the incident becomes after an authorized change goes wrong.

Before enabling AI agents that can create, modify, or administer Cognos content, organizations should have, at minimum:

• A dedicated Cognos identity for each AI use case, scoped only to the content and capabilities required.
• Read and write privileges separated wherever practical, with administrative privileges treated as a distinct risk tier.
• A human approval step before bulk, destructive, security, configuration, deployment, or other high-impact actions.
• A non-production or sandbox Cognos environment for testing agent behavior before it reaches production.
• A current content store backup and deployment strategy.
• A tested recovery process, including a clear answer to how individual content changes will be restored without unnecessarily rolling back unrelated work.

Cognos 12.1.3 Changes the Recovery Conversation

This is also where upgrading to the latest Cognos release matters. Cognos Analytics 12.1.3 adds native source-control integration with GitHub and GitLab. IBM documents the ability to commit supported Cognos assets, track changes, compare versions, recover previous versions, and maintain history outside the Content Store.

That is a meaningful improvement over relying only on content store backups and deployment archives. It gives teams a more modern way to apply development and change-management practices to supported Cognos content.

There are still important limitations to evaluate. IBM states that, as of 12.1.3, deleted Cognos content cannot be restored through the new source-control capability. Source control also has to be configured and used as part of a disciplined operating process. Simply upgrading does not automatically create a complete recovery strategy.

Where Motio CI Fits Now

The arrival of native source control changes how Motio CI should be positioned. Motio CI is not the control that makes an overprivileged MCP identity safe, and it should not replace credential scoping, approval gates, sandbox testing, Cognos backups, or the native source-control capabilities available in 12.1.3.

Motio CI is better understood as an additional resilience, change-management, and recoverability layer. For organizations that need more mature governance around Cognos content, the relevant question is no longer whether Cognos has any native version history. It is whether the combination of native Cognos capabilities and your existing operating processes provides the depth of history, granularity, automation, governance, comparison, and recovery your environment requires.

That evaluation should be based on your specific content types, deployment practices, development model, compliance requirements, and tolerance for recovery time and data loss. The objective is not to buy another tool by default. It is to know exactly how you will recover when a human or AI makes a change you need to reverse.

Think in Three Layers: Prevention, Native Protection, and Resilience

A strong Cognos AI control architecture can be evaluated in three layers:

Layer 1: Prevention. Cognos permissions and capabilities, dedicated MCP identities, least privilege, human approvals, and sandbox testing.

Layer 2: Native protection. Content store backups, deployment archives, and Cognos 12.1.3 GitHub/GitLab source control for supported assets.

Layer 3: Operational resilience. Additional change-management, versioning, rollback, governance, and recovery capabilities where native controls do not fully meet the organization’s requirements.

This layered approach avoids two extremes: treating AI as too risky to use, or assuming that enterprise governance automatically makes every AI action safe. The goal is controlled adoption with a known blast radius and a tested way back.

The Upgrade Conversation Is Now a Security and Governance Conversation

If you are on an older Cognos release, the case for upgrading should not be evaluated only as a feature checklist. Cognos Analytics 12.1.3 introduces capabilities that affect AI adoption, development workflows, automation, and recoverability. For organizations considering agentic AI, those capabilities can become part of the control architecture itself.

At the same time, upgrading can expose new decisions. Which AI capabilities should be enabled? Which users or service identities should receive them? How should Git-based source control be configured? What still requires Motio CI or another layer of change control? Which administrative actions should never be autonomous?

Those answers will be different for every Cognos environment. Your current version, architecture, content inventory, security model, regulatory obligations, development practices, and recovery requirements all matter.

Frequently Asked Questions About Cognos MCP Risk

Does MCP bypass Cognos security?

It should not be treated as a bypass around Cognos authorization. Cognos applies permissions and capabilities to authenticated consumers, including applications. The primary design question is therefore what permissions and capabilities are granted to the identity being used by the AI.

Should an MCP user have Cognos administrator access?

Not by default. Report consumption, content development, and administration carry very different risk profiles. Administrative access should be isolated, tightly scoped, and subject to stronger approvals and monitoring.

Does Cognos 12.1.3 have native version control?

Yes. Cognos Analytics 12.1.3 adds source-control integration with GitHub and GitLab for supported assets, including history, comparison, and recovery of prior versions. IBM currently notes that deleted Cognos content cannot be restored through this feature in 12.1.3.

Does native source control eliminate the need for Motio CI?

Not necessarily. Native source control is a major improvement. Organizations should compare it with their actual requirements for automation, governance, granular rollback, content coverage, development workflows, compliance, and recovery. Motio CI may provide an additional resilience layer where those requirements exceed the native capability or current process.

What should we do before enabling agentic AI in Cognos?

Start with a permissions review. Define the AI use cases, create appropriately scoped identities, separate consumer, developer, and administrator privileges, test in non-production, establish approval gates for high-impact actions, and validate both native and supplemental recovery options before production rollout.

Know Your Unique Cognos Security Risk Before You Scale AI

There is no universal “safe MCP configuration” for every Cognos customer. A financial services organization with tightly controlled production reporting has a different risk profile from a decentralized analytics team with hundreds of authors. An older Cognos environment has different recovery options from a team running 12.1.3 with source control configured.

Lodestar Solutions can help you assess your current Cognos version, security model, MCP and agentic AI use cases, backup and rollback readiness, and the gaps between your current controls and the capabilities now available in Cognos 12.1.3.