How should organisations secure AI agents alongside human identities and NHIs at industry events and runtime meetings?

Treat AI agents as active identities, not just applications. Use strong identity proofing, least privilege, and explicit session boundaries for every human, machine, and agent interaction. Segregate event access from production access, require short-lived credentials where possible, and log all requests for later review. The goal is to prevent an agent from inheriting trust that was meant for a person or service.

Why This Matters for Security Teams

Industry events and runtime meetings compress trust into a narrow window: badge access, shared calendars, collaboration tools, demo sandboxes, and AI assistants can all intersect in one workflow. That is exactly where identity boundaries fail. An AI agent should not inherit the same access assumptions as a presenter, a salesperson, or a support bot. The risk is not just data leakage; it is privilege transfer across systems that were never meant to share a session.

This is why agentic AI guidance now treats the agent as an active identity with its own lifecycle, not a passive application. The OWASP Agentic AI Top 10 and the NIST AI Risk Management Framework both point toward runtime controls, context-aware authorization, and bounded execution. NHIMG research shows how quickly trust breaks when secrets and tokens spread beyond their intended scope, including exposed tokens in collaboration tools and code systems in the 2025 State of NHIs and Secrets in Cybersecurity. In practice, many security teams discover identity sprawl only after an event demo account, meeting assistant, or agent workflow has already been reused outside its intended boundary.

How It Works in Practice

Securing AI agents alongside humans and NHIs starts with separating event identity from production identity. A conference demo, customer workshop, or internal runtime meeting should use its own short-lived trust domain, distinct from core systems. That means time-bound credentials, scoped API access, and explicit approval for each tool the agent can call. For agents, static RBAC is usually too blunt because the work is goal-driven and the sequence of actions is not fixed in advance. Current guidance suggests moving toward intent-based authorization, where policy is evaluated at request time with the full context of who requested the action, what the agent is trying to do, and where the action will land.

In practical terms, teams should combine workload identity with just-in-time access. A service or agent proves what it is through cryptographic identity, then receives an ephemeral token only for the task at hand. Standards such as SPIFFE and OIDC are useful here because they support workload-centric identity rather than credential reuse. Runtime policies should be enforced through policy-as-code, not meeting-by-meeting manual decisions. That is how organisations keep an assistant from becoming a bridge between a public event environment and privileged back-end systems. NHIMG’s reporting on agent compromise and token exposure, including the CoPhish OAuth Token Theft via Copilot Studio and the Moltbook AI agent keys breach, is a reminder that an exposed token is often the first step in lateral movement, not the last.

Common control points include:

• Separate event, meeting, and production tenants or projects wherever possible.
• Issue per-session credentials with short TTLs and automatic revocation.
• Require explicit approval before an agent can access files, calendars, CRM, or code.
• Log every tool call, prompt, token issuance, and privilege change for review.
• Use break-glass access only for humans, never as a default path for agents.

These controls tend to break down when a single meeting stack is tied directly to production data sources because the event workflow then becomes a live privilege bridge.

Common Variations and Edge Cases

Tighter event controls often increase friction for speakers, facilitators, and support staff, so organisations must balance usability against blast-radius reduction. The hard part is not only technical isolation; it is deciding when a temporary agent is allowed to cross boundaries at all. Best practice is evolving, but there is no universal standard for treating an agent in a live meeting the same way across all industries. Some environments will need read-only agents for note capture, while others may permit controlled write actions such as ticket creation or calendar updates.

Edge cases appear when one agent serves many attendees, when a vendor-hosted meeting assistant shares infrastructure with customer workflows, or when a demo environment must mimic production data. Those scenarios require stronger segregation, because a compromise in one session can spill into many. For deeper context on agent-specific attack paths, see the Analysis of Claude Code Security and the OWASP NHI Top 10. The lesson is consistent: meeting access is not inherently benign just because it is temporary. A short meeting token can still become a durable foothold if it is copied, forwarded, or chained into another workflow.

Where guidance gets weaker is in hybrid environments that rely on legacy collaboration tools, shared admin accounts, or vendor-managed bots. In those cases, organisations should document the exception, constrain the duration, and retire the workflow as soon as a safer identity pattern is available.

Related resources from NHI Mgmt Group

• Why do organisations struggle to secure AI agents and other non human identities in day to day operations?
• What is the difference between managed identities and hardcoded secrets for AI agents?
• Why do AI agents make non-human identity governance harder?
• Why do AI agents create new risk in non-human identity management?