IBM Is Preparing for a Very Different Kind of AI

Most people became familiar with generative AI through chatbots. A user asks a question, the AI generates a response and the interaction ends.

Agentic AI changes that relationship.

An AI agent can potentially receive a goal, determine the steps required to accomplish it, choose tools, interact with applications, retrieve information, call other services and continue working with limited human involvement.

That makes AI considerably more useful, but it also gives the technology something traditional chatbots generally did not have: operational authority.

If an AI system can read company databases, update customer records, reset passwords, interact with financial systems, modify code or communicate with other applications, cybersecurity can no longer focus only on whether the model gives a bad answer.

Security teams also have to control what the AI can actually do.

That is the problem IBM is attempting to address across several parts of its artificial intelligence, cybersecurity, identity and hybrid-cloud portfolio.

What IBM Announced on September 28

IBM announced its support for NVIDIA’s Open Agent Safety Platform, an open software platform and reference architecture designed to strengthen the security surrounding AI agents as they move from testing into real production environments.

IBM is bringing together technology from several parts of its enterprise portfolio.

• IBM Agent Identity for establishing identifiable AI-agent identities and authorization.
• HashiCorp Vault for managing credentials, secrets and short-lived access.
• IBM Identity Protection for visibility into identities and associated risk.
• IBM Storage and IBM Fusion for infrastructure and data protection.
• Red Hat OpenShift for deploying governed AI workloads across hybrid environments.
• watsonx Orchestrate for building, registering, managing and governing AI agents.

The significance is not simply that IBM and NVIDIA are collaborating on another AI technology.

The larger idea is that AI security cannot depend entirely on telling the AI to behave correctly.

Security controls increasingly need to exist outside the model, where the agent cannot simply reinterpret or ignore them.

Why an AI Agent Needs Its Own Identity

One of the most important parts of IBM’s strategy is a concept known as Agent Identity.

Traditional identity and access management systems were designed primarily around people, applications, devices and predictable machine accounts.

AI agents create a more complicated situation because an agent may operate independently while still working on behalf of a human user.

Consider a simple example.

An employee may have administrator access to a human-resources system. The employee asks an AI agent to retrieve a list of open positions.

If the agent automatically inherits the employee’s complete permissions, it may receive far more authority than the task requires.

The agent may only need permission to read a limited set of information, yet it could inherit privileges capable of altering employees, changing records or performing administrative operations.

IBM is proposing a different model.

The human remains the person requesting the task, but the AI agent receives its own identifiable enterprise identity.

Instead of an audit record simply showing that an employee accessed an application, the organization can preserve information showing that a particular AI agent accessed the system on that employee’s behalf.

That distinction can become extremely important for cybersecurity investigations, compliance, auditing and accountability.

Give AI Only the Access It Actually Needs

IBM is applying one of cybersecurity’s longstanding principles to artificial intelligence: least privilege.

A system should receive only the permissions required to perform its assigned task and no more.

Instead of permanently providing an AI agent with broad credentials, IBM’s approach moves toward narrower, shorter-lived authorization.

An agent performing a particular operation could receive temporary access appropriate for that task. Once the authorization expires, the agent no longer retains the standing privilege.

This matters because a compromised, incorrectly configured or manipulated AI agent with permanent administrative access could potentially affect many systems before the problem is discovered.

Limiting both the scope and duration of access reduces the possible blast radius.

HashiCorp Vault Adds Another Security Layer

HashiCorp Vault is another important component of IBM’s strategy.

Enterprise systems frequently rely on passwords, API keys, certificates, database credentials and other sensitive secrets. Permanently embedding those credentials into an autonomous AI agent creates obvious security concerns.

Vault is designed to protect those secrets and provide controlled credentials when they are needed.

In an agentic environment, a more secure workflow can look like this:

1. A human requests an action.
2. The authorized AI agent receives the task.
3. The agent’s identity and authorization are checked.
4. The agent receives only the credentials required for the task.
5. Those credentials can be narrowly scoped and short-lived.
6. The action is recorded for auditing.
7. The temporary authorization expires when it is no longer needed.

That is fundamentally different from handing autonomous software an unrestricted administrator password or permanent API key.

NVIDIA Is Adding a Security Boundary Outside the AI Agent

IBM’s strategy becomes especially interesting when combined with NVIDIA’s Open Agent Safety Platform.

One important component is NVIDIA OpenShell.

OpenShell is designed to create an enforceable runtime boundary around an AI agent.

Instead of relying only on instructions written into the model’s prompt, organizations can enforce policies governing which systems, tools, APIs and resources an agent can use.

In practical terms, an organization may establish rules such as:

• This agent may access this database.
• It may read these records.
• It may call these approved APIs.
• It may communicate with approved network destinations.
• It may not access other systems.
• It may not obtain credentials outside its assigned authorization.

The important distinction is that the security boundary exists around the agent instead of relying solely on the agent to obey instructions.

That matters because AI agents can be affected by faulty reasoning, configuration mistakes, malicious instructions and attacks such as prompt injection.

NVIDIA Sentry Adds Infrastructure-Level Monitoring

NVIDIA’s Open Agent Safety Platform also includes a reference system design known as Sentry.

Sentry is designed to provide an additional security layer outside the AI workload itself using NVIDIA infrastructure technologies.

This reflects a familiar cybersecurity concept: defense in depth.

Instead of relying on one security mechanism, organizations can combine several independent protections.

• Model safeguards
• Agent identity
• Authorization policies
• Temporary credentials
• Sandboxing
• Runtime monitoring
• Network restrictions
• Infrastructure security
• Hardware-assisted security controls
• Auditing and traceability

If one layer fails, another layer may still prevent an unauthorized action from spreading through the environment.

Why Security Cannot Live Only in the Prompt

One of the most important ideas behind IBM’s strategy is that an instruction written into an AI prompt is not the same thing as a security control.

Those are very different levels of protection.

This distinction becomes increasingly important as agents gain the ability to operate for longer periods, interact with multiple applications and make decisions without asking a person for approval at every step.

Reliable cybersecurity controls should be enforced by systems that the technology being controlled cannot simply override.

Why This Is Becoming Urgent

The timing of IBM and NVIDIA’s work is important.

As AI agents become more autonomous, developers and security teams must prepare for situations in which software behaves differently from what its creators expected.

That does not mean every AI agent is inherently unsafe.

It reinforces a principle cybersecurity professionals have relied upon for decades: powerful software should not be trusted merely because its developer expects it to behave correctly.

Security architecture has to assume that errors, manipulation, configuration problems and unexpected behavior can occur.

That is why IBM’s identity model and NVIDIA’s containment technology deserve attention beyond the companies directly involved.

watsonx Orchestrate Is Becoming IBM’s AI-Agent Control Plane

Identity is only one part of IBM’s broader strategy.

IBM is expanding watsonx Orchestrate into an environment where organizations can register, run, monitor and govern AI agents.

This matters because large organizations are unlikely to use AI agents from only one vendor.

A company could eventually have agents developed through IBM, Amazon, Microsoft, Google, open-source frameworks and internal development teams.

Without centralized management, businesses could face a new version of an old cybersecurity problem: technology operating inside the organization that security teams do not fully know about.

IBM refers to part of this concern as the problem of shadow agents.

Watsonx Orchestrate is being designed to help discover and manage agents across different environments rather than requiring every agent to be built exclusively with IBM technology.

IBM Can Trace What an Agent Actually Did

Another important capability is Trace Inspector.

Instead of simply recording whether an AI task succeeded or failed, Trace Inspector can show the execution path of an agent run.

That can include which tools the agent called and where its behavior departed from what developers expected.

IBM has also introduced custom agent-evaluation capabilities and an AgentOps Agent intended to help test, diagnose and improve AI agents.

This represents an emerging discipline sometimes described as AgentOps: applying monitoring, evaluation, troubleshooting and operational management to AI agents in much the same way DevOps and observability tools are used to manage conventional software.

IBM Is Still Developing Its Own AI Models

IBM’s security strategy should not be mistaken for abandoning AI-model development.

IBM Research released Granite 4.2, a generation of its open Granite models designed specifically with agentic workloads in mind.

Granite 4.2 emphasizes capabilities such as reasoning, instruction following, coding and tool use.

Tool use is especially important for autonomous AI.

A traditional chatbot primarily generates language. An agent must determine which application or tool should be used, when it should use it and what should happen after that action.

IBM is therefore developing several layers at the same time:

• Granite provides AI models.
• watsonx Orchestrate manages and coordinates agents.
• Agent Identity establishes who an agent is.
• HashiCorp Vault controls credentials and secrets.
• Identity Protection provides additional risk visibility.
• Red Hat OpenShift provides a hybrid-cloud operating platform.
• NVIDIA technologies provide additional runtime and infrastructure security controls.

Taken together, the broader IBM strategy becomes much clearer.

IBM Is Bringing AI to the Data

Another important part of IBM’s strategy involves where enterprise AI processing occurs.

Many organizations hold highly sensitive information on IBM systems, especially in banking, insurance, government and other transaction-intensive environments.

IBM SQL Data Insights Pro applies AI-assisted analysis directly to enterprise data on IBM Z.

Instead of requiring an organization to copy sensitive information into another external AI platform, certain forms of analysis can occur closer to where that information already resides.

Potential applications include anomaly detection, fraud analysis, behavior analysis and identifying relationships that conventional exact-match database queries may not reveal.

Why Businesses Should Learn About This Now

Even organizations that are not currently using IBM technology should pay attention to what is happening.

1. AI Is Moving From Information to Action

The security requirements for software that writes text are very different from those of software that can perform transactions, change records, deploy code or access business applications.

2. AI Agents Are Becoming Non-Human Identities

Cybersecurity teams already manage employees, service accounts, applications, devices and machines.

AI agents may become another major identity category that needs to be inventoried, authenticated, authorized, monitored and eventually deactivated.

3. Permanent Credentials Create Risk

Giving an autonomous agent a long-lived API key or administrator credential may be convenient, but convenience can create substantial security exposure.

Short-lived and narrowly scoped credentials provide a safer model.

4. Businesses Will Need an Inventory of Their AI Agents

Organizations cannot secure technology they do not know exists.

As departments begin creating agents independently, businesses may eventually need formal agent inventories just as they maintain inventories of computers, employees, applications and cloud resources.

5. AI Auditing Will Become More Important

When an AI agent performs work, organizations may need to answer not only what happened, but which agent did it, who authorized it, which permissions it received, which tools it used and which data it accessed.

6. AI Security Is Becoming Infrastructure Security

IBM and NVIDIA are moving AI-agent security beyond the application layer into identity systems, credentials, runtimes, networks, infrastructure and hardware.

That is an important indication of where enterprise AI may be heading.

This Matters to Smaller Businesses Too

IBM’s technology is heavily oriented toward enterprise environments, but the underlying security principles apply much more broadly.

A smaller company may eventually deploy an AI agent capable of:

• Reading and answering email.
• Updating a CRM.
• Accessing analytics accounts.
• Modifying website content.
• Creating support tickets.
• Generating invoices.
• Interacting with cloud storage.
• Managing calendars.
• Using payment or e-commerce systems.

Before giving an AI system those capabilities, businesses should ask:

• Does this agent have its own account or identity?
• What information can it access?
• Does it really need write access?
• Are its credentials permanent or temporary?
• Which external systems may it communicate with?
• Are sensitive actions subject to human approval?
• Can its actions be audited afterward?
• Can its access be revoked immediately?
• What happens if the agent behaves unexpectedly?

Those questions are likely to become standard parts of cybersecurity planning as AI automation expands.

What IBM Has Not Solved

These announcements should not be interpreted as evidence that autonomous AI has suddenly become risk-free.

Agent Identity does not prevent an AI model from making a reasoning error.

Sandboxing does not guarantee that every policy will be configured correctly.

Infrastructure isolation does not eliminate social engineering, malicious input, software vulnerabilities or human configuration mistakes.

Some of these newest identity and security technologies are also still developing and have not yet become universally deployed enterprise standards.

The more accurate interpretation is that the technology industry is beginning to build the security architecture that increasingly autonomous AI systems will require.

That is significant because it acknowledges that model-level guardrails alone are not enough.

What to Watch Next

• Agent identity standards: whether interoperable standards emerge for identifying agents across vendors and cloud platforms.
• Cross-platform governance: whether organizations can govern agents built through many different AI ecosystems from a common control layer.
• Temporary authorization: greater adoption of just-in-time access rather than permanent API keys and standing permissions.
• Human approval: high-risk transactions may increasingly require explicit human authorization before an agent can proceed.
• Agent observability: businesses will need records showing what agents attempted, which tools they used and why actions were allowed or blocked.
• Infrastructure-enforced security: more AI security controls may move below applications and into runtimes, networks and hardware.
• Regulation and compliance: organizations will need to determine how existing privacy, identity, security and auditing requirements apply when software agents perform real actions.

The Bigger Technology Story

IBM’s latest AI work reflects a much larger shift taking place across the technology industry.

The first phase of generative AI was largely about capability.

Agentic AI introduces a different question.

That question brings artificial intelligence directly into the disciplines of identity management, zero-trust security, privileged-access management, credential protection, observability, audit logging, network security and infrastructure isolation.

IBM appears to be positioning itself less as another consumer-AI company and more as a provider of infrastructure enterprises will need to operate AI systems across complex business environments.

Whether IBM’s specific architecture becomes an industry standard remains to be seen.

But the security problem it is addressing is likely to become increasingly difficult for businesses to ignore.

What Businesses Should Do Now

Businesses do not need to deploy every new AI technology simply because it becomes available.

They should, however, begin preparing for a future in which AI systems have significantly more access and authority than today’s chatbots.

Organizations experimenting with AI agents should begin documenting:

• Which agents are being used.
• Who owns each agent.
• Which systems each agent can access.
• Which credentials and API keys are involved.
• Whether access can be narrowed.
• Which actions require human approval.
• How agent activity is logged.
• How an agent can be immediately disabled.

Companies should also avoid giving experimental AI tools unrestricted access to production systems simply for convenience.

The fundamental cybersecurity principles have not changed: identify everything, authenticate it, grant only the access required, monitor what it does and maintain the ability to revoke that access.

What has changed is that those principles now need to include artificial intelligence.

Final Takeaway

IBM’s work with NVIDIA represents more than another artificial-intelligence product announcement.

It shows that enterprise AI is entering a stage where security architecture may become just as important as model intelligence.

AI agents are beginning to act more like digital workers, software services and automated operators.

If that evolution continues, organizations will need to know which agents exist, establish their identities, restrict their privileges, protect their credentials, monitor their behavior and maintain a reliable record of important actions they perform.

IBM is betting that identity, governance, hybrid cloud and cybersecurity will become fundamental infrastructure for this new AI environment.

For businesses, developers and cybersecurity professionals, that transition is worth understanding now.