How should security teams prepare for AI security conversations at AWS re:Inforce events?

Framing the Conversation Around AI Risk at AWS re:Inforce

Security teams get the most value from AWS re:Inforce when they treat AI discussions as governance and control conversations, not product demos. That means coming prepared to discuss where AI systems ingest sensitive data, how outputs are approved, what audit trail exists, and which users or services can invoke AI capabilities on the organisation’s behalf. The right questions surface whether the current design can be trusted at scale, not whether the technology sounds promising.

For broader AI governance context, the CSA MAESTRO agentic AI threat modeling framework is a useful external reference because it helps teams structure questions around agent behaviour, trust boundaries, and misuse paths rather than treating AI as a generic application layer. In practice, many security teams encounter their first serious AI governance gaps only after a pilot has already expanded into shared use.

What to Test in Workshops, Booth Meetings, and Side Conversations

At an event, the most useful preparation is to carry a small set of concrete scenarios and test them against each AI use case. Security teams should be able to explain what happens if a model is asked to summarise confidential data, trigger an action, or retrieve content from a connected system. They should also be ready to ask who approves those workflows, how exceptions are recorded, and what evidence exists when a model or agent acts incorrectly.

That conversation becomes more productive when it is anchored in specific control questions:

• Which data classes can be used for prompting, retrieval, training, or evaluation?
• Which identities, roles, or service accounts can call the AI system or its tools?
• What logging exists for prompts, outputs, tool calls, and privilege changes?
• How are unsafe outputs, overbroad access, and prompt injection scenarios handled?
• What changes when the AI system is integrated with internal workflows or external APIs?

The strongest event discussions usually reveal whether the organisation is still testing ideas or already operating a production dependency. That distinction matters because once an AI capability is connected to live identity, data, or automation paths, missing approvals and weak telemetry become operational issues rather than policy gaps. For agentic systems, the Anthropic Project Glasswing reference can help teams think about higher-order coordination and control concerns where autonomous behaviour changes the risk profile.

Where this guidance breaks down is when an organisation cannot yet describe its AI inventory, access model, or data flows with enough precision to evaluate any use case meaningfully.

Where AI Discussions Usually Go Off Track Before Deployment

Tighter AI adoption often increases governance overhead, requiring organisations to balance speed of experimentation against control of data, identity, and action scope.

One common failure is focusing on model capability while ignoring the workflow around it. A system may appear low risk in isolation, yet become materially different once it can read internal content, write to tickets, send messages, or call downstream services. Another issue is treating all AI systems the same. Guidance vs consensus: the industry has not fully settled how to standardise controls for agentic AI, so teams should be explicit about whether they are discussing chat interfaces, retrieval systems, or autonomous agents.

Security teams should also watch for two edge cases. First, pilots that rely on manual supervision can create a false sense of safety if the same supervision will not be sustainable in production. Second, event conversations may assume clean separation between AI and identity controls, but in practice the AI layer often inherits privilege, logging, and approval weaknesses from the surrounding environment. The useful question is not whether the model is safe in principle, but whether the organisation can prove that actions, data access, and exceptions are constrained in the real operating model.

Where this advice becomes less effective is in highly bespoke environments where AI is embedded so deeply into business workflows that the limiting factor is no longer the model itself, but the quality of upstream identity, data, and approval governance.

Risk and Threat Considerations

AI security conversations at events can expose material risk around data leakage, over-privileged automation, and weak governance over agentic behaviour. The main exposure is not just model misuse, but the way AI systems inherit trust from the identities, tools, and datasets they can reach.

Failure mechanism: Risk materialises when prompts, retrieval sources, or tool calls are not tightly scoped, allowing sensitive information to be exposed or actions to be triggered outside intended approval paths. In adversarial settings, prompt injection, data poisoning, and abuse of connected tools can steer outputs or actions in ways the operator did not intend.

Impact: The practical consequence is loss of confidentiality, unapproved execution, inaccurate decision support, or downstream compromise of connected systems. Once an AI workflow is wired into business operations, weak logging or unclear ownership can also make incident investigation and accountability significantly harder.

Practitioner Guidance

What to prioritise: Start with the use cases that combine sensitive data, external connectivity, and autonomous action. Those combinations create the fastest path from “interesting demo” to real operational exposure.

What to verify: Confirm that teams can explain who approves the AI workflow, what data it can see, what it can do, and what evidence is retained when it acts. If any of those answers are vague, the conversation is not ready for deployment decisions.

Decision rule: If the AI system can influence a business action, treat it as a governed operational control, not as a standalone feature request. If it cannot yet be monitored and constrained, keep it in evaluation mode.

Practitioner takeaway: The most useful event preparation is a short list of concrete control questions that expose whether an AI initiative is merely experimental or already creating identity, data, and automation risk.

Related resources from NHI Mgmt Group

• How should security teams prepare for AI security events that bring together builders, researchers, and defenders?
• How should security teams prepare for AI security governance at large cloud conferences and enterprise events?
• How should security teams prepare for AI security risk ahead of major industry events and product roadmaps?
• How should partner teams prepare for security-focused customer conversations about AI applications and agents?