Orca MCP Server shows how AI assistants can query cloud risk

At a glance

What this is: This is Orca Security’s overview of its MCP Server, which connects AI assistants to cloud security data for natural-language investigation and reporting.

Why it matters: It matters because AI-assisted security workflows change how identity, access, and remediation decisions are surfaced, making governance of NHI and autonomous-style tooling harder to ignore.

By the numbers:

• When AWS credentials are exposed publicly, attackers attempt access within an average of 17 minutes, and as quickly as 9 minutes in some cases.
• The average estimated time to remediate a leaked secret is 27 days, despite 75% of organisations expressing strong confidence in their secrets management capabilities.

👉 Read Orca Security's overview of the MCP Server for cloud security context

Context

Orca Security’s MCP Server sits at the intersection of cloud security operations and identity governance. The primary keyword here is MCP, or Model Context Protocol, which lets an AI assistant connect to security data sources and act on them through natural language rather than a fixed console workflow.

The governance question is not whether better context helps analysts. It does. The real issue is whether AI-mediated access to cloud risk data can be tightly scoped, audited, and separated from the broader identity and entitlement model that already governs humans, service accounts, and other non-human identities.

That makes this a useful case study for teams trying to decide how far to let AI into security operations. The starting point is typical: teams want faster context and less console friction, but the control model has to keep pace with the access pattern.

Key questions

Q: How should security teams govern AI assistants that query cloud security data?

A: Security teams should govern AI assistants that query cloud security data as privileged non-human access paths. Define exactly which tools, datasets, and outputs are allowed, then separate read-only insight generation from any action that can change configuration or remediation state. The assistant should inherit least privilege, logging, and review requirements like any other sensitive service integration.

Q: Why do AI-assisted security workflows increase identity risk in cloud environments?

A: AI-assisted security workflows increase identity risk because they add a new pathway into sensitive telemetry, asset context, and remediation intelligence. If that pathway is over-broad, the assistant can expose more operational detail than a human analyst would normally see, expanding the blast radius of a compromised account or token.

Q: What breaks when cloud security platforms expose too much context through an AI assistant?

A: What breaks is the assumption that context is harmless if it is only being read. Once an assistant can combine alerts, assets, permissions, and attack paths, it can reveal organisational structure, exposed secrets, and weak entitlement boundaries. The result is a richer target map for both attackers and over-permissioned insiders.

Q: How do IAM teams decide whether an AI security assistant needs its own access controls?

A: IAM teams should give an AI security assistant its own access controls whenever it can query sensitive security data across multiple systems. If the assistant can retrieve executive reports, attack paths, or remediation details, it is no longer just a user interface. It is a governed identity path that needs explicit ownership, review, and auditability.

Technical breakdown

How MCP connects AI assistants to security data

Model Context Protocol is an open standard for connecting an AI assistant to external tools and data sources. In this pattern, the assistant does not just summarise text. It can invoke tools that query cloud posture, asset context, alerts, or attack paths, then return structured results in natural language. The security value is speed and breadth of retrieval. The security risk is that tool access becomes part of the trust boundary, so the assistant’s scope matters as much as the underlying dataset. Practical implication: treat MCP tool access as governed access, not as a harmless UI enhancement.

Practical implication: treat MCP tool access as governed access, not as a harmless UI enhancement.

Why context-rich querying changes the NHI security model

Cloud security platforms already rely on machine identities, API permissions, and service-side access paths. MCP adds another layer that can aggregate and expose that context to an AI assistant. That means the assistant inherits a governed pathway into security data, even if it is only being used to read and summarise. The important point is that context is now an access surface, not just an output. If the assistant can retrieve high-value security data, the organisation must define who can use it, what data it can touch, and how the results are logged and reviewed. Practical implication: align MCP usage with the same access review discipline used for other privileged non-human identities.

Practical implication: align MCP usage with the same access review discipline used for other privileged non-human identities.

Blast-radius analysis depends on identity and entitlement boundaries

Orca’s attack-path and blast-radius use case shows how security teams increasingly want AI to connect the dots across assets, permissions, and potential lateral movement. That is useful only if the underlying identity relationships are accurate. If permissions are stale, over-broad, or poorly mapped, the assistant can produce a confident but misleading risk narrative. In other words, AI does not replace entitlement hygiene. It consumes it. Practical implication: prioritise entitlement accuracy, asset ownership, and permission lineage before relying on AI-assisted blast-radius analysis.

Practical implication: prioritise entitlement accuracy, asset ownership, and permission lineage before relying on AI-assisted blast-radius analysis.

Threat narrative

Attacker objective: The objective is to extract enough cloud security context to accelerate targeting, privilege mapping, or follow-on compromise.

1. Entry begins when an AI assistant or operator gains access to cloud security context through an MCP-enabled tool connected to the Orca environment.
2. Escalation occurs if the assistant can retrieve broader security records, permissions, or attack-path details than the task actually requires, expanding the effective blast radius of the query path.
3. Impact is the exposure of sensitive posture, asset, or remediation context that can accelerate adversary discovery if the surrounding identity controls are weak.

Breaches seen in the wild

• Cisco DevHub NHI breach — IntelBroker exploited exposed Cisco credentials, API tokens and keys in DevHub.
• ASP.NET machine keys RCE attack — 3,000+ exposed ASP.NET machine keys enabled remote code execution.

Read our 52 NHI Breaches Analysis report for a comprehensive view of breaches impacting Non-Human Identities including AI Agents.

NHI Mgmt Group analysis

MCP turns cloud security context into a governed access problem, not just an interface problem. The moment an AI assistant can query alerts, assets, and remediation data, the organisation has introduced another identity-mediated path into sensitive operational intelligence. That path must be treated like any other privileged workload or service integration. The implication is that AI-assisted security operations need explicit entitlement design, not just prompt design.

Context-rich analysis exposes the real weakness in many cloud programmes: inaccurate permission lineage. If the AI assistant can assemble attack paths and blast radius from incomplete or stale identity data, the output may look authoritative while hiding structural gaps. That means the quality of identity, asset ownership, and entitlement mapping is now part of operational risk. Practitioners should treat data accuracy as a control dependency, not a reporting detail.

Unified data models create a new category of non-human decision support that sits between humans and automation. This is not autonomous behaviour in the strict sense, but it does shift how security work is executed because the assistant can select and combine tools inside a governed workflow. That widens the governance surface for NHI teams, IAM leads, and security architects. The implication is that identity programmes must classify AI-assisted tooling as a privileged access pattern, even when it is read-mostly.

Identity blast radius is the right concept for this pattern. The more context an AI assistant can retrieve across cloud posture, alerting, and attack paths, the more the organisation must understand how far a single query path can travel through data and permissions. That is a governance issue, not just a workflow benefit. Practitioners should define blast radius for the assistant itself, not only for the assets it inspects.

Security teams will increasingly need separate guardrails for insight generation and action generation. A system that summarises risk is not the same as a system that changes policy or triggers remediation, but both can inherit excessive trust if they use the same access path. This distinction matters because it keeps AI assistance from quietly becoming privileged execution. The implication is to split read, decide, and act into different control planes.

From our research:

• When AWS credentials are exposed publicly, attackers attempt access within an average of 17 minutes, and as quickly as 9 minutes in some cases, according to LLMjacking: How Attackers Hijack AI Using Compromised NHIs.
• Deep inspection of leaked-secret cases found that the average estimated time to remediate a leaked secret is 27 days, according to The State of Secrets in AppSec.
• For a broader threat-pattern view, use The 52 NHI breaches Report to compare how exposed credentials become attack paths across real incidents.

What this signals

Identity blast radius now includes the assistant itself. As more teams connect AI tools to cloud security data, the governance question shifts from what the platform knows to what the assistant is allowed to retrieve and combine. That is why NHI and IAM teams need to classify these connectors as privileged access patterns, not productivity features. The practical next step is to align them with authoritative controls such as NIST Cybersecurity Framework and the access-path discipline described in 52 NHI Breaches Analysis.

The risk increases when AI queries can traverse fragmented secrets and entitlement estates. With organisations maintaining an average of 6 distinct secrets manager instances, according to The State of Secrets in AppSec, the assistant may be operating against an incomplete control picture. Teams should treat fragmentation as a governance signal, not just an operational inconvenience.

Decision support and decision execution need different guardrails. If the same assistant can summarise risk and trigger follow-on action, the organisation has blended two control planes that should remain separate. Practitioners should map where human approval, service-account mediation, or policy enforcement sits between insight and remediation, then validate those boundaries against the connected toolchain.

For practitioners

• Classify MCP-enabled AI access as a privileged identity path Inventory every AI assistant or chatbot that can reach cloud security data, then map the exact tools, datasets, and permissions it can invoke. Require approval and periodic review for that access path just as you would for a privileged service account.
• Separate read-only context retrieval from remediation authority Allow AI assistants to summarise alerts, assets, and blast radius without granting the same identity path to execute changes. Keep remediation actions behind distinct approvals, service accounts, or human-controlled workflows so insight generation cannot drift into execution.
• Validate entitlement lineage before trusting blast-radius output Check whether the platform’s asset ownership, permission inheritance, and role mappings are current enough to support AI-assisted analysis. If the underlying identity graph is stale, the assistant may amplify bad data rather than improve decision quality.
• Log and review every high-value AI query path Record which assistant, user, and tool combination retrieved executive summaries, malware context, or attack-path data, then review those logs for unusual scope or frequency. This creates an audit trail for AI-mediated security access and supports access review decisions.

Key takeaways

• AI assistants connected through MCP create a governed access path into cloud security context, so identity controls matter as much as the model prompt.
• The main operational risk is not AI reasoning quality alone but the breadth of data, permissions, and blast radius the assistant can traverse.
• Security teams should separate insight generation from remediation authority and review MCP access with the same discipline used for privileged non-human identities.

Key terms

• Model Context Protocol: Model Context Protocol is an open standard that lets an AI assistant connect to external tools and data sources. In security operations, it turns the assistant into a governed consumer of cloud, alerting, or asset context, so the access path must be controlled, logged, and reviewed like any other privileged integration.
• Blast Radius: Blast radius is the amount of data, systems, or operational context exposed if an identity or tool path is abused. For AI-assisted security workflows, it includes not just the target asset but the assistant’s ability to traverse alerts, permissions, and remediation context across the environment.
• Non-Human Identity: A non-human identity is any machine or workload credential used to access systems, data, or services. In practice this includes service accounts, API keys, tokens, certificates, and AI-connected tooling that can operate under delegated access.
• Identity Lineage: Identity lineage is the traceable relationship between an identity, its permissions, and the resources it can reach. It matters when AI tools retrieve security context because stale or incomplete lineage can make risk analysis look precise while hiding over-permissioned paths and ownership gaps.

Deepen your knowledge

NHI governance, agentic AI identity, and machine identity security are core topics in our NHI Foundation Level course, the industry's only accredited NHI security programme. If you are responsible for identity security strategy or NHI governance in your organisation, it is worth exploring.

This post draws on content published by Orca Security: The Orca MCP Server. Read the original.