TL;DR: Amazon Q Developer connected to an MCP server can surface cloud-security context, shorten investigation paths, and support secure coding workflows inside a GenAI interface, according to Orca Security. The real governance question is whether teams can safely expose security data and action paths to AI-assisted tools without weakening identity boundaries or overextending access assumptions.
At a glance
What this is: Orca Security demonstrates Amazon Q Developer connected to an MCP server as a way to query cloud-security context and accelerate investigation and secure coding workflows.
Why it matters: This matters because cloud security teams need to decide what data and actions AI-assisted tools can reach without eroding identity boundaries, auditability, or least-privilege expectations.
Context
Amazon Q Developer is being used here as a GenAI interface for cloud-security workflows, with the Orca MCP Server acting as the bridge to cloud context and security data. The key governance issue is not whether the assistant can answer questions, but whether exposing live security context to a tool-driven interface changes the access model around investigation and remediation.
MCP is an open protocol for connecting applications and models to tools and data sources, which makes it attractive for security workflows that need context fast. In identity terms, the question is who or what is authorised to retrieve, combine, and act on that context, especially when the workflow sits between human operators, cloud data, and developer tooling.
Key questions
Q: How should security teams govern MCP-enabled AI assistants that can act on tools and data?
A: Treat MCP-enabled assistants as non-human identities with scoped authority, not as passive interfaces. Put a policy decision point between interpretation and execution, require explicit confirmation for privileged actions, and restrict which context sources the assistant may trust. Governance should focus on preventing unverified input from becoming executable intent.
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 context is exposed to GenAI tools without tight scoping?
A: The control assumption that only a human analyst sees a bounded slice of data breaks down. A model-mediated workflow can combine inventories, findings, and relationships in ways the operator did not explicitly navigate, so context minimisation and field-level scoping become necessary to preserve governance intent.
Q: What should teams do if they want AI chat to support secure coding and cloud triage?
A: Use separate permissions for investigation, summarisation, and any action-bearing workflow, and require attributable logging at each boundary. That lets teams benefit from faster analysis without turning the assistant into a broad-purpose proxy for cloud access.
Technical breakdown
How MCP brokers tool and data access for cloud security workflows
MCP gives an application a standard way to present tools, context, and data to a model-driven client. In this pattern, the assistant is not magically seeing the environment on its own. It is requesting data through a defined server boundary that can expose cloud inventory, findings, and other operational context. That matters because the security properties live in the server-side permissions, not in the chat interface. If the MCP server can query broad cloud data, then the assistant inherits that reach unless the environment constrains scope, query types, and result handling.
Practical implication: treat the MCP server as a governed access layer, not a convenience wrapper.
Why GenAI chat changes the cloud security investigation model
A chat interface compresses discovery, triage, and summarisation into one interaction, which can make cloud-security investigations feel faster and more natural. The architectural shift is that the user is no longer navigating separate consoles and dashboards first. Instead, the assistant can assemble answers from multiple security sources on demand. That improves workflow efficiency, but it also increases the importance of query boundaries, data minimisation, and output control. If the assistant can surface vulnerable containers or account relationships too freely, it can also expose more than the operator intended.
Practical implication: limit which cloud datasets the assistant can query and what it can return.
Amazon Bedrock, Amazon Q, and the trust boundary around delegated access
Amazon Q and Amazon Bedrock provide the runtime context for the interaction, while the MCP server mediates access to Orca data. The trust boundary therefore spans identity, model orchestration, and the data source itself. This is not a classic application-session problem, because the interface is mediated by multiple services that can transform the request before it reaches the underlying security platform. The practical question is whether delegated access remains tightly attributable and reversible when a human asks an assistant to inspect cloud risk on their behalf.
Practical implication: define attribution, logging, and revocation points across the full delegation chain.
Breaches seen in the wild
- Amazon Q Developer extension compromise 2025: An over-scoped CI token let an attacker ship a prompt telling Amazon Q's AI coding agent to wipe files and AWS resources (CVE-2025-8217).
- Amazon Q MCP config vulnerability 2026: A malicious .amazonq/mcp.json in a repository could make Amazon Q run commands with a developer's AWS credentials. Fixed before disclosure.
Read and download The State of NHI & AI Agent Breach Report 2026, covering 200+ breaches impacting Non-Human Identities including AI Agents.
NHI Mgmt Group analysis
AI-assisted cloud investigation creates an access-governance problem before it creates a productivity gain. The article is really about delegated visibility into cloud-security data through a model-mediated interface. That shifts the control question from whether analysts can move faster to whether the identity boundary around security data remains intelligible once a GenAI layer starts aggregating context across sources. Practitioners should treat the assistant as another governed access path, not a neutral chat surface.
MCP is a context-distribution mechanism, so its security value depends on how tightly context is scoped. When an MCP server exposes cloud findings, inventories, or account summaries, the assistant inherits whatever access model the server enforces. If the server is over-broad, the GenAI layer becomes an amplifier for that over-breadth rather than a remediation layer. The right lens is least privilege for context retrieval, not just least privilege for API calls.
Identity boundary dilution is the central governance risk in model-assisted security workflows. The more a team relies on chat to retrieve, summarise, and compare cloud-security data, the easier it becomes to blur who requested the data, which identity executed the query, and what downstream artefacts should be auditable. That matters across human IAM and NHI governance because the assistant may sit on top of service credentials, delegated tokens, or platform-level permissions. Practitioners should preserve attribution from user intent to tool execution.
Security teams should expect the market to move toward context-rich control planes, not isolated AI features. The pattern here is not unique to one vendor or one assistant. It signals that cloud-security platforms will increasingly be judged by how safely they expose operational context to AI-driven workflows, especially where investigation and secure coding are converging. The decisive question is whether governance can keep pace with speed.
For cloud-security programmes, the next step is to govern AI access to evidence, not just to actions. Asking an assistant to recommend remediation is one thing. Letting it query the environment, summarise risk, and expose findings across accounts is another. That means policy, logging, and review processes need to cover what context the assistant can see, how results are retained, and who can authorise expansion of those permissions.
From our research library:
- 24,008 unique secrets were exposed in MCP configuration files in 2025 alone, the protocol's first year of widespread adoption, according to the State of Secrets Sprawl 2026.
- 52% of respondents see AI security decision-making power shifting toward platform and infrastructure teams rather than the executive suite, according to the 2026 Infrastructure Identity Survey.
- Read next: MCP Security Guide
What this signals
Identity boundary dilution: once a GenAI assistant sits between a practitioner and the cloud platform, the programme has to govern context exposure as carefully as it governs remediation rights. The question is no longer only who can change the environment, but who can ask the assistant to retrieve enough context to reconstruct it.
Teams should expect AI-assisted cloud operations to push more governance pressure onto access scoping, attribution, and logging. When the same assistant can summarise findings, query accounts, and support secure coding, the organisation needs a clear rule for which identity is actually authorised to obtain each layer of context.
The practical inflection point is not whether GenAI can help with cloud security. It is whether the security function can preserve least privilege when a conversational interface becomes the front door to investigative data and operational knowledge.
For practitioners
- Define the MCP server trust boundary Classify the MCP server as a controlled access layer and limit it to the smallest cloud-security datasets required for the task. Review which tools it can call, which accounts it can query, and which fields it can return to the assistant.
- Scope delegated query permissions tightly Separate read-only investigative queries from any workflow that could trigger changes, and ensure the assistant cannot silently inherit broader platform permissions than the human operator would normally receive.
- Log the full delegation chain Record the requesting user, the assistant session, the MCP server action, and the source account or dataset so that reviews can trace who caused a query and what data was exposed.
- Review cloud-security data minimisation Reduce the default context available to the assistant by removing fields that are not needed for triage, especially when results may surface vulnerable containers, account relationships, or compliance gaps.
Key takeaways
- AI-assisted cloud security workflows do not remove identity risk. They shift it toward delegated access, context exposure, and auditability across the assistant and the underlying data source.
- The main governance issue is not model intelligence but scope control. If the MCP server is over-broad, the assistant can amplify that over-breadth into a larger access problem.
- Teams should separate read-only investigation from action-capable workflows and preserve logging that traces the user, the assistant session, and the server-side query path.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
OWASP Non-Human Identity Top 10 and OWASP Agentic AI Top 10 address the attack and risk surface, while NIST CSF 2.0 and NIST SP 800-53 Rev 5 set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| OWASP Non-Human Identity Top 10 | NHI-04 — Insecure Authentication | The article hinges on delegated access into cloud data through an MCP server. |
| NHI-05 — Overprivileged NHI | The main risk is over-broad server-side access inherited by the assistant. | |
| Recommendation — Authenticate MCP server access with tightly scoped, attributable identities for each assistant workflow. Constrain MCP server privileges to the minimum cloud datasets and actions required for each use case. | ||
| OWASP Agentic AI Top 10 | ASI03 — Identity & Privilege Abuse | Model-mediated tool use can magnify delegated privilege if boundaries are weak. |
| Recommendation — Restrict agent tool permissions so assistants cannot exceed the operator’s intended privilege scope. | ||
| NIST CSF 2.0 | PR.AA-05 — Access Permissions, Entitlements and Authorizations | Cloud-security query paths need explicit permission governance and review. |
| Recommendation — Review and document entitlements for AI-assisted cloud investigation workflows before expanding access. | ||
| NIST SP 800-53 Rev 5 | IA-9 — Identification and Authentication (Non-Organizational Users) | The assistant workflow depends on controlled authentication to cloud and data services. |
| Recommendation — Use service-to-service authentication controls to keep delegated AI access traceable and revocable. | ||
Key terms
- MCP Server: An MCP server is a tool endpoint that connects an AI agent to external systems and data sources through Model Context Protocol. Because it extends what the agent can reach, it becomes part of the identity and access surface and must be reviewed like any other privileged connector.
- Delegated access path: A delegated access path is the chain of identities, tokens, connectors, and approvals that lets one system act through another. It becomes a governance concern when the path outlives the original approval or can be reused for actions beyond the intended business purpose.
- Identity Boundary Dilution: Identity boundary dilution occurs when a workflow makes it harder to tell which identity requested data, which executed the action, and which one should be held accountable. AI-mediated tools can blur these lines unless logging and authorisation boundaries are preserved end to end.
- Session Exposure: The risk that authenticated browser activity reveals cookies, tokens, page content, or navigation history to an untrusted component. For browser-based access, session exposure can create downstream compromise even when the original login was legitimate and multi-factor protected.
Deepen your knowledge
NHI governance, agentic AI identity, and machine identity lifecycle are core topics in our NHI Foundation Level course, the industry's only accredited NHI security programme. If you are building or maturing an IAM programme, it is worth exploring.
Published by the NHIMG editorial team on June 12, 2026.
Updated on October 10, 2026.
NHI Mgmt Group, the independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org