Session 4: Secure by Design — Baking Identity Controls into the AI Agent Development Lifecycle | Non-Human & Agentic AI Identity Summit @ Identiverse 2026
Speakers: Jesse Minor, Identity Security Expert, KPMG | David Chan, Director of IAM, USC | Henrique Teixeira, SVP of Strategy, Saviynt | Shashwat Sehgal, Founder & CEO, P0 Security
In this session from the Non-Human & Agentic AI Identity Summit at Identiverse 2026, four identity and security practitioners get into the practical specifics of what secure AI agent deployment actually looks like — and confront the uncomfortable reality that for most organisations, agents are already in the environment before any of these controls exist.
The session opens with a deliberately blunt framing. Agentic AI is not coming. It is already here, already inside organisations, and already creating risk that most identity teams haven’t fully mapped. Citizen developers are deploying agents using consumer AI tools that actively suggest bad practices — storing credentials in environment files, hardcoding API keys — and the majority of the people building these agents have had no security training. Gartner data cited during the session suggests more than 90% of CISOs overestimate their understanding of AI, while only 8% of leaders report having deployed AI agents in production in a controlled way. The gap between what organisations think is happening and what is actually happening is significant.
David Chan anchors the risk conversation in a framework he describes as pre-incident, during-incident, and post-incident. Before a rogue agent incident occurs: do you have separate identities for agents rather than borrowed admin credentials, just-in-time token issuance, architectural standards for what good looks like? During an incident: do you have the visibility and logging needed to detect when an agent is behaving outside of its intended boundaries, and do you even know what agents are running in your environment? After an incident: can you recover, and have you actually tested recovery in a time-sensitive scenario? These aren’t abstract governance questions — they are the immediate practical baseline that most organisations are nowhere near meeting.
Shashwat Sehgal identifies the single most critical design challenge: delegation chains. When an agent calls a sub-agent, which calls another sub-agent, the provenance of every action in the execution chain becomes opaque. The foundational requirement before anything else is an agentic identity that tracks the originating user and every intermediate agent at every point in the chain. Without that, auditors have nothing to work with and security teams have no forensic trail when something goes wrong.
Henrique Teixeira raises the challenge of how agents are being bootstrapped in the first place. The problem isn’t just that agents are being deployed without proper controls — it’s that the tools developers are using to deploy them are teaching bad habits at scale. His practical answer: corporate policy has to define what a compliant agent deployment looks like, mandate registration through a central identity store rather than local credential files, and make the compliant path as simple as the non-compliant one. If the friction to do the right thing is too high, developers will bypass it. The experience for a citizen developer needs to be simple — point to a gateway, bootstrap cleanly, and inherit the controls automatically.
Teixeira also introduces the asbestos analogy that resonates through the rest of the session: static credentials are the asbestos of the identity world. The immediate priority is to stop building new systems with them. The second priority is to find and remediate the agents that were already deployed without proper controls before those environments become the attack path.
The panel then moves to the challenge of external agents — AI systems from SaaS platforms, third-party vendors, and cloud providers that operate within an organisation’s environment but outside its direct control. David Chan makes the point that the scope of identity accountability doesn’t stop at the workforce boundary. Whether a breach originates from an internal agent or an external one, the security team is accountable. The panel’s consensus is that internal and external agents cannot be governed by the same policy framework — the degree of control is fundamentally different — which means organisations need distinct policy sets for each agent type, not a single unified approach. Peeling that further, different categories of agent likely warrant different policies again, based on what they can access and what they can do.
The session closes on a practical note. Discovery is the non-negotiable starting point. You cannot govern what you cannot see. Even a spreadsheet registry of known agents is better than nothing. From there: stop using static credentials, enforce short-lived tokens, create a central registration and bootstrapping mechanism, and build the policy foundation that everything else can be layered on top of.
