By NHI Mgmt Group Editorial TeamPublished 2025-06-16Domain: Agentic AI & NHIsSource: Orca Security

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: This is Orca Security's analysis of using Amazon Q Developer with an MCP server to query cloud security data and support secure coding workflows.

Why it matters: It matters because AI-assisted cloud operations shift identity and access decisions into conversational interfaces, where NHI, workload, and delegated access controls must remain explicit.

👉 Read Orca Security's analysis of Amazon Q Developer with the Orca MCP Server


Context

MCP, or Model Context Protocol, is a way to let AI tools reach internal context and services through a structured interface. In this post, the key issue is not the chatbot itself but the identity boundary created when cloud security data becomes queryable through an AI assistant. That raises questions for NHI, workload identity, and delegated access governance.

For IAM teams, the important change is that security work no longer stops at the application boundary. If Amazon Q Developer can interrogate cloud environment data through an MCP server, then the control surface extends to the identities, permissions, and data paths behind that connection. The governance challenge is to keep that exposure auditable, scoped, and reversible.


Key questions

Q: How should security teams govern AI assistants connected to cloud security data?

A: Treat the assistant as a delegated access path, not a harmless interface. Every connector should have a named owner, a narrow scope, and an audit trail that records which identity asked, which system answered, and what data was returned. If the assistant can reach sensitive cloud context, it needs the same governance discipline as any other privileged integration.

Q: When does an MCP server create excess identity risk?

A: Risk rises when the server can query more systems, data classes, or environment context than the task requires. The problem is not MCP itself, but scope creep in the connected identities and permissions. If a conversational request can reveal broad cloud posture without strong boundaries, the assistant becomes a privilege amplifier rather than a productivity layer.

Q: What do teams get wrong about AI-generated security summaries?

A: They often treat summaries as if they were evidence. In practice, the summary is only a translation layer over underlying data, which may be incomplete, stale, or overbroad. Security teams should verify the source records, confirm the access path, and decide whether the assistant should be allowed to expose that class of information at all.

Q: How do organisations keep human review in AI-assisted cloud operations?

A: Make human approval the gate for any action that changes access, remediates risk, or triggers investigation. The assistant can help locate findings and compress analysis, but it should not be the final decision-maker. That preserves accountability and prevents conversational convenience from replacing governance.


Technical breakdown

How MCP exposes cloud context to AI tools

MCP provides a structured protocol for connecting applications to context, data, and services that an AI system can use during a session. In this pattern, the MCP server becomes the bridge between the assistant and internal systems, while the assistant remains the user-facing interface. The security consequence is that the protocol does not create access by itself, but it does make underlying entitlements operationally relevant to the AI workflow. That means the real control point is not the model prompt, but the permissions and data scope attached to the MCP connection.

Practical implication: treat MCP server permissions as production access and review them with the same rigor as any other privileged integration.

Amazon Q Developer, Bedrock, and delegated runtime access

Amazon Q Developer sits on top of Amazon Bedrock and can interact with tools and internal data sources through the MCP server. That creates a delegated runtime access model where the AI assistant can retrieve environment-specific information on behalf of a user. The governance issue is whether the delegated scope matches the task, especially when the assistant can move from general questions to security-sensitive queries. This is a familiar IAM problem in a new interface: if the delegated session is too broad, the assistant becomes a high-speed path to overexposure rather than a productivity aid.

Practical implication: map every AI-assisted query path to a named identity, a bounded scope, and a logged decision trail.

Secure coding workflows for cloud-native applications

The article frames the use case around secure coding and cloud-native application analysis, where AI can help surface vulnerable containers, account relationships, and environment summaries. Mechanically, that works because the MCP layer makes cloud security data queryable in a conversational flow. The risk is that convenience compresses review discipline, especially if users start treating AI-generated summaries as authoritative without checking source context. For security architecture, this is less about model accuracy in the abstract and more about whether human approval, escalation, and evidence handling still exist after the AI has simplified the workflow.

Practical implication: require human verification for AI-generated security summaries before they drive remediation or access decisions.


NHI Mgmt Group analysis

MCP is becoming an identity boundary, not just an integration pattern. Once cloud security data is reachable through an assistant, the control problem shifts from simple tool connectivity to governed delegation. That means the security team is now managing who can ask what, which identities can answer, and how much environment context can be exposed in one session. Practitioners should treat MCP as part of the identity plane, not the application layer.

AI-assisted cloud operations compress the gap between insight and action. In a normal workflow, analysts inspect findings, compare sources, and then act. With Amazon Q Developer connected to an MCP server, the same interface can summarize, retrieve, and guide faster than a manual review loop. That speed is useful, but it also narrows the time available to spot overbroad permissions, stale context, or unsafe assumptions. Teams should assume the workflow will be used at operational speed, not training speed.

Least privilege remains the correct model, but the enforcement point moves. The relevant question is no longer whether users can access cloud findings, but whether the assistant can reach more context than the task requires. This is where NHI governance, delegated access, and workload identity meet. If the MCP server is over-scoped, the assistant inherits that excess scope and can surface more sensitive information than the human operator would otherwise touch.

Named concept: prompt-mediated privilege expansion. This is the pattern where a conversational request causes an AI-enabled workflow to traverse more data and context than a conventional UI would expose in the same moment. It does not require a breach to be dangerous. Practitioners should recognise it as a governance issue in which interface convenience can widen effective privilege even when formal entitlements appear unchanged.

This pattern validates cross-domain identity governance across human, NHI, and AI-assisted workflows. The human asks, the assistant brokers, and the backend systems answer through machine identities and scoped integrations. That chain only works safely when each step is independently governed, logged, and reviewable. Security leaders should align IAM, NHI, and cloud platform teams around the full delegation path, not just the front-end assistant.

From our research:

  • 70% of organisations grant AI systems more access than they would give a human employee performing the exact same job, according to the 2026 Infrastructure Identity Survey.
  • Only 44% of organisations have implemented any policies to manage their AI agents, despite 92% agreeing that governing AI agents is critical to enterprise security.
  • That combination makes Analysis of Claude Code Security the right next step for practitioners evaluating governed AI-to-tool access patterns.

What this signals

Prompt-mediated privilege expansion: As AI assistants become the interface for cloud security work, effective privilege can widen even when formal entitlements appear unchanged. Teams should expect the governance bottleneck to move from UI convenience to delegated access design, with auditability and scope control becoming the deciding factors.

With 69% of security leaders saying identity management must fundamentally shift to address agentic AI systems, per the 2026 Infrastructure Identity Survey, the planning horizon is already beyond experimental use cases. IAM and cloud platform teams should prepare for operational requests that arrive through assistants rather than portals.

The practical signal for practitioners is simple: if AI can reach sensitive cloud context faster than a human analyst can review it, then review cadence is no longer the control boundary. The programme needs explicit rules for what the assistant may see, what it may summarise, and what still requires direct human inspection.


For practitioners

  • Scope MCP server access as privileged integration Inventory every data source, service, and environment the MCP server can reach, then classify that access as production-grade privilege. Limit each connector to the smallest query surface needed for the security use case, and review it alongside other workload identities and service accounts.
  • Bind assistant requests to named identities Ensure each Amazon Q Developer session is tied to a specific user identity, environment, and audit record so queries are not anonymous or reusable outside their intended context. Log the source identity, target system, and returned data class for every sensitive interaction.
  • Require evidence before security summaries drive action Do not let AI-generated findings move directly into remediation tickets, access changes, or incident decisions without human review of the underlying cloud data. Use the assistant for acceleration, but keep the verification step in the workflow.
  • Review delegated access paths for scope creep Check whether the assistant can traverse beyond the task that triggered the request, especially when cloud security summaries expose account lists, container risk, or compliance data. Recut any path that turns a narrow question into broad environment visibility.

Key takeaways

  • MCP-connected assistants turn cloud security access into an identity governance problem, not just an AI interface problem.
  • When AI systems can query broad cloud context, over-scoped delegated access becomes a privilege amplifier even without a breach.
  • Practitioners should bind assistant sessions to named identities, limit connector scope, and keep human verification in the decision path.

Standards & Framework Alignment

This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.

OWASP Agentic AI Top 10 and OWASP Non-Human Identity Top 10 address the attack and risk surface, while NIST CSF 2.0 set the governance and control requirements practitioners need to meet.

FrameworkControl / ReferenceRelevance
OWASP Agentic AI Top 10AG-02MCP-connected assistants can widen tool and data access inside agent workflows.
OWASP Non-Human Identity Top 10NHI-04The MCP server functions as a privileged non-human access path to cloud data.
NIST CSF 2.0PR.AA-01Identity and access management applies to assistant-mediated cloud operations.

Map AI assistant access to identities, entitlements, and audit evidence under access governance.


Key terms

  • Model Context Protocol: A structured protocol that lets an application expose context, data, and services to an AI system. In practice, it becomes an access boundary that determines what the model can query or retrieve during a session, so its permissions and logging matter as much as the model itself.
  • Delegated Access Path: A route through which one identity or interface acts on behalf of another to reach systems, data, or actions. For AI-assisted workflows, this is the path that turns a user request into machine-executed access, so it must be scoped, auditable, and reversible.
  • Prompt-Mediated Privilege Expansion: A governance pattern where a conversational request causes an AI-enabled workflow to surface more data or context than a normal workflow would expose. The formal permissions may look unchanged, but the practical privilege widens because the interface can traverse more systems or return more sensitive detail.
  • Cloud Security Summary: A condensed security view produced from underlying cloud data, often used to accelerate analysis or remediation. It is not evidence on its own, because it depends on source systems, access scope, and the freshness of the queried data that fed it.

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: Amazon Q Developer with the Orca MCP Server. Read the original.

NHIMG Editorial Note
Published by the NHIMG editorial team on 2025-06-16.
NHI Mgmt Group — the independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org