On the same week NIST announced its AI Agent Standards Initiative, IBM released a video guide on architecting secure AI agents. This isn't coincidental timing — it reflects the industry arriving at a critical inflection point where AI agent security moves from experimental to essential.
Jeff Crume, IBM Distinguished Engineer and Security Architect, presents the core concepts from IBM's collaboration with Anthropic: "Architecting Secure Enterprise AI Agents with MCP." It's the first enterprise security framework specifically for AI agents, and it directly addresses the questions NIST is asking.
The Paradigm Shift We're Living Through
Crume opens with a fundamental observation: AI agents represent a shift from deterministic to probabilistic systems. This isn't just a technical distinction — it changes how we think about security.| Traditional Systems | AI Agent Systems |
|---|---|
| Deterministic (same input → same output) | Probabilistic (same input → variable output) |
| Static environments | Adaptive environments that learn | Focus on implementation correctness | Focus on evaluation of outcomes |
| Security through access control | Security through behavior monitoring |
For healthcare, this shift is profound. We've spent decades building security models around "if user X has role Y, they can access resource Z." That model assumes deterministic behavior — the user either accesses the resource or doesn't.
Agents don't work that way. An agent might access a resource in unexpected ways, combine data from multiple sources, or take actions that weren't explicitly anticipated when permissions were granted. Security must move from gatekeeping access to monitoring behavior.
Agent Development Lifecycle (ADLC)
IBM introduces the Agent Development Lifecycle — a structured methodology that extends DevSecOps for AI agents:- Planning — Define acceptable agency, business goals, behavior specs
- Coding — Develop prompts, tool integrations, orchestration
- Testing — Evaluation-first approach with guardrailed testing
- Debugging — Address non-deterministic behaviors
- Deploying — Staged rollout with sandboxing
- Monitoring — Continuous observation of outcomes
- Continuous Planning — Iterate based on real-world performance
The key insight is that agent development is cyclical, not linear. You don't deploy an agent and walk away. You deploy, monitor, learn, and adjust — continuously.
For healthcare organizations evaluating AI agent vendors, ask: "What is your ADLC process?" If they can't articulate a structured lifecycle that includes security at every phase, they're not ready for healthcare deployment.
The Security Threats Are Real
Crume identifies five ways agents expand the attack surface:- Excessive Access — Agents granted more permissions than necessary
- Privilege Escalation — Agents acquiring permissions beyond authorization
- Data Leaks — Sensitive information exposed through responses or logs
- Prompt Injection — Malicious content redirecting agent behavior
- Attack Amplifiers — Agents used to scale attacks across systems
In healthcare, these aren't abstract risks:
- Excessive Access → An agent with broad EHR permissions can access any patient record, not just the ones relevant to its task
- Privilege Escalation → An agent discovers it can approve orders or modify records beyond its intended scope
- Data Leaks → PHI surfaces in agent responses, logs, or training data
- Prompt Injection → A malicious document in a patient record redirects an agent to exfiltrate data
- Attack Amplifiers → A compromised agent propagates across connected clinical systems
This is why NIST is asking for industry input on agent security. These threats are emerging now, in production systems.
IBM's Security Framework
The guide presents a three-layer security framework:1. Identity and Access Management (IAM)
Agents need to be managed as non-human identities — first-class principals with their own credentials, permissions, and audit trails.- Unique credentials for each agent (not shared service accounts)
- Just-in-time access (credentials issued when needed, revoked after)
- Full auditing of agent actions tied to agent identity
This aligns directly with what I've been calling Agent Identity in the Multi-Layered AI Identity framework. IBM validates the approach: agents are identity principals, not just software processes.
2. Securing Data and Models
- AI firewalls/proxies that inspect agent traffic
- Prompt injection detection at the gateway
- Data loss prevention (DLP) controls
The concept of an "AI firewall" is becoming standard architecture. This is the centralized gateway pattern we've discussed — a control point where all agent traffic passes through for inspection.
3. Threat Detection and Risk Assessment
- Proactive threat hunting for agent-specific attacks
- Continuous risk assessment as agents operate
- Anomaly detection for agent behavior
Notice the emphasis on continuous assessment. You don't just evaluate an agent at deployment and trust it forever. You monitor behavior continuously because agent behavior can drift over time — through learning, through environmental changes, or through attack.
How This Connects to NIST
The timing of IBM's video alongside NIST's announcement isn't coincidental. Look at how IBM's framework maps to what NIST is asking:| NIST Question | IBM Framework Component |
|---|---|
| How might agents be identified? | Non-human identity management |
| What constitutes strong authentication? | Unique credentials, just-in-time access |
| How do we establish least privilege? | RBAC, sandboxing, defined acceptable agency |
| What controls prevent prompt injection? | AI firewalls, gateway inspection |
| How do we ensure auditable logging? | IAM audit capabilities, continuous observation |
IBM and Anthropic have essentially provided a reference implementation for what NIST is exploring. If you're preparing comments for the NIST RFI (due March 9) or the NCCOE concept paper (due April 2), this IBM guide is valuable source material.
What's Still Missing
IBM's framework is strong on the components I've called Agent Identity, Tool Identity (via RBAC and sandboxing), and observability. But there's less emphasis on two areas:Data Identity
The guide addresses DLP, but doesn't deeply explore classification-aware access control. In healthcare, this matters: an agent shouldn't just be blocked from sending PHI externally — it should be restricted from accessing data above its classification ceiling in the first place.Intent Identity
Crume mentions aligning agents with business goals, but doesn't address how to verify that alignment continuously during execution. Theintent_hash approach — capturing the original request and comparing actions against it throughout execution — isn't part of IBM's current framework.
This is the gap I've been focused on. Traditional identity (who is acting) and traditional authorization (what are they allowed to do) aren't sufficient for agents. We also need intent verification (why are they acting, and has that purpose drifted).
Practical Takeaways for Healthcare
1. Adopt the ADLC mindset. Whether you use IBM's specific methodology or not, the principle matters: agent development is a continuous lifecycle with security integrated throughout. Document your process.2. Treat agents as non-human identities. If your agents are using shared service accounts or long-lived credentials, fix that. Each agent needs its own identity with auditable actions.
3. Implement just-in-time access. For PHI access especially, agents should receive credentials only when needed for a specific task. Long-lived credentials for agents accessing patient data are a compliance risk.
4. Plan for AI gateways. The centralized gateway pattern — where agent traffic passes through an inspection point for prompt injection detection and DLP — is becoming standard. Evaluate whether your architecture supports this.
5. Shift from "is it up?" to "is it right?" Traditional monitoring asks whether systems are available. Agent monitoring must ask whether agents are behaving correctly. Build observability that captures agent actions and outcomes, not just availability metrics.
6. Prepare for human-in-the-loop requirements. The EU AI Act requires human oversight for high-risk AI in healthcare. Even if you're not subject to EU regulation, design for human-in-the-loop now. It will be required somewhere, eventually.
The Convergence Is Happening
Today's news — NIST launching its AI Agent Standards Initiative and IBM releasing practical security guidance — represents a convergence. The industry is arriving at consensus on the problems (agent identity, authorization, prompt injection, observability) even if the solutions are still being refined.For healthcare security practitioners, this convergence is good news. It means the standards and frameworks are coming. It also means the window for "we're still figuring this out" is closing.
If you're deploying AI agents in healthcare — or evaluating vendors who are — now is the time to build the foundation. The frameworks are emerging. The questions are defined. The next step is implementation.
This is entry #20 in the AI Security series. For the full IBM video with detailed practitioner notes, see the Learning Center resource. For NIST's related initiative, see NIST Launches AI Agent Standards Initiative.