Latest / TeqTalk with Jas / AI Agent Identity Explained: Who Controls What Your Agents Can Do?
Transcript
- Ep74 Final: The IT department of every company is going to be the HR department of AI agents in the future. When you join a company, you get a batch. Someone in IT creates your account, gives you access to the systems your role needs, and the day you leave, they switch it all off. That system has worked for three decades now. The AI agent your company deployed last. It reads your CRM, it drops email, maybe it approves an invoice. They can take actions on your behalf and under your control. How do we ensure the guardrails and they stick to what we want them to do and under our control? So let me ask you three questions. Who issued its login? What exactly can it open? And when it does something at two in the morning, whose name shows up in the audit log? If you hesitated on any of those, you're not alone. If you want to have the business benefits and you want to have the security, you have to secure the identity that all these agents interact with. You can always put guardrails on the outside, right? Agents now get their own identity permissions, policies, access controls. Palo Alto Network's 2026 Identity Security Landscape Report, a survey of nearly 3,000 security leaders, put the ratio at 109 machine identities for every human. And Of those 109 roughly 79 are AI agents. So the batch model isn't just stretched, it's outnumbered. I'm Jess, this is Tech Talk, and today your AI agent has a login. Here is the plan for the next 10 to 15 minutes. First, how identity worked before agents. The world we built for people and for programs. Second, the four places where agents actually break that world. Third, the new identity layer being built right now. Five ships you need to understand. Fourth, what Microsoft, Okta, Peng, and Sale Points are actually building. And fifth, the scorecard. What are shipped, what is still a draft, and where it is heading towards. Then I'll leave you with one test you can run on any agent in your company this week. To understand what's changing you need to see what we build. Enterprise identity grew up in three layers basically. So first layer is people. A directory like Active Directory holds every employee. Single sign-on lets you log in once. MFA proves it's really you. And the role-based access says if you are in finance, you get the finance systems. People are unpredictable, but they are accountable. There is a name on every action. Led to is applications. When one app needed to talk to another, we created a service account or an API key. Basically, a password for a program. Then in 2012, OAuth 2.0 gave us something better: Delegated Access. You have seen it as a thousand times now. This app would like to access your calendar. Would you allow? Yes. You click. Allow once the app gets a token with a set of permissions called scopes and it keeps that access until someone revokes it. Layer third is cloud workloads. Containers and microservices got short-lived identities, cloud IAM roles and standards like SPIFE, SPI, FFE. Now notice the assumption underneath all three layers. Every actor was either a person. Unpredictable but really accountable. Or a program, not accountable, but predictable. It does the same thing every single time. An EI agent is neither. It decides at runtime like a person, but it's a software with no HR record. No accountability on its own, running at machine speed. So our identity stack was never built for this kind of actor. So what actually has got wrong? Let me walk you through a sandbox test. A vendor payment agent running on sample data. With no governance layer, wired up the quick way a lot of agents get wired up today. Four things can break. Break 1. Borrowed identity. The fastest way to give an agent access is to hand it a person's credentials or a shared API. In the sandbox, the agent ran on a test user's token. So when it updated a vendor record, the log said the test user did it. The agent is invisible. And in the real company, the real person would be on the hook for something they never did. Break 2. Standing privilege. That token was granted once with broad permissions because nobody could predict which tasks the agents would take on. Think about it, an employee's job changes every few months. An agent's task changes every few seconds. So you cannot know at setup time what it'll need. So the easy path is to over-grant it. And that access just sits there forever. Break number three is delegation chains. Our payment agent called a research agent, which called a document too. Three hops. The rule should be simple: every hop only should narrow the permissions, never widen them. But a standard OAuth key has no clean way to say agent B acting for agent A acting for this user with less access than both. Break number four is. Consent built for humans. OAuth assumes a person clicking allow. Agents do not sit in front of a consent screen at 2 in the morning. So either the agents get blocked or someone pre-approves everything. Right back to break two. This isn't a fringe concern. OWASP's first top 10 for agent applications published in December 2025 gives identity and privilege abuse its own category. And readiness is pretty low. Okta's AI at work survey found that fewer than a third of organizations consistently govern AI agents the way they govern human workers. But here is the good news. The industry has stopped arguing about whether this is a problem. Well, it is building the fix and it comes down to five shifts now. Shift number one, the agent gets its own identity, not your login, not a shared key, a first-class identity registered in a directory like an employee. With a name human owner. Every majority identity vendor now offers this. Well, I'll show you four of them in a few minutes. And on AWS, every agent deployed on Bedrock Agent Core gets its own workload identity automatically. The principle is simple: if you cannot name it, you cannot govern it. And when that owner leaves the company, the agent doesn't become an orphan. Ownership moves to someone else or the agent is switched off. Shift number two. And if you remember one idea from this episode, make it this one. Two identities in every request. When an agent acts for you, it should act on your behalf, not as you. So it authenticates as itself and carries your identity alongside as a separate claim. In OAuth language, the agent is the client and you are the subject. Now the log reads payment agent on behalf of this user did this. Accountability is back. And you can restrict the agent separately from the person. Shift number three, the company decides, not the consent screen. That allow button is being replaced for enterprise agents by standard call ID JAG, Identity Assertion, JWT Authorization Grant. Okta Markets it has cross-app access. And here is how it works. The agent asks your company identity provider, and this user is signed in. Can I reach the project tool for her? The identity provider checks policy and if IT approved that connection, hands back a short-lived, signed letter on introduction, naming the agent, the user and the app. The agent trades that letter for a narrowly scoped token. No pop-up and when IT turns it off, it's off everywhere. Shift number four. No more static secrets. A key in the file proves possession, not identity. Anyone holding it is the agent. The new model is cryptographic workload identity, short-lived certificates that rotate automatically, plus token vaults, so the agent never handles the raw credentials. In practice, the agent's credentials last minutes, not months, and if it leaks, it has already expired. AWS Agent Code Token WALT, for example, releases a credential only when the agent presents verifiable proof of its workload identity. Shift number 5, authorization becomes continuous. Now old model, check once at login. New model, check every action in context. Microsoft has extended conditional access and ID protection for agents. The same risk policies we already use for employees. And the latest MCP specification supports step up authorization. Which means if an agent tries something beyond its current permission, it has to go back to earn more instead of being overgranted up front. So put those five together and now you get a very different picture. Not the agent has a login, instead, the agent has its own identity, a human owner and a narrow short-lived permission for one user, for one task, and every step is checked and logged. Principles are the easy part though. So who is actually shipping this? Let's get concrete. Four vendors, three jobs, Microsoft and Okta compete over where an agent's identity lives. Ping builds the checkpoint an agent passes through every time it acts. Sale point builds the audit. Who owns this agent and should it still have the access? Microsoft intra agent ID is not generally available. The idea of worth stealing is the blueprint. One template for a family of agents, with each agent getting its own identity. And if you disable the blueprint, every agent built from it stops. Every agent also needs a sponsor. A named business owner. On top sits Agent 365, generally available since May 1st. The catch is that many agent governance features need an Agent 365 or E7 license. Octaver AI agents went generally available on April 13th. Agents become first class identities with a human owner and it hunts for shadow agents like Employee Connected on their own. Its signature feature is a kill switch that revokes the agent's tokens everywhere. Add agent SSO, cross-app access from shift 3. And Okta's bet is clear. Be the neutral identity layer across every app and every AI vendor. Well, Ping identity. Identity for AI reached general availability in March. Ping's focus is runtime, delegated access through token exchange. The on behalf of pattern from shift 2 and an agent gateway in front of MCP servers. That checks the delegation, enforces scopes, and audit every call. Sale point comes from governance point of view. The Access Reviews auditors ask for. In August it launched AgentIc Fabric, now generally available. It discovers agents, their credentials, and MCP servers, assigns a human owner to every machine account, and adds a central off-switch. It also announced a deal for intro, which maps machine identities back to their own owners. Well, Sales point question is not can this agent really log in? It is should it still have this access and who signs off? So this is my opinion. Microsoft fits if you live in Microsoft 365, Okta if you need neutrality across many apps, ping leads on runtime enforcement, sale point on governance, and all four agree on three things. Every agent gets his own identity, a human owner, and an off switch. So where we are as of October 2026. Things which are shipped, agent identities in major directories, the latest MCP specification with tighter authorization rules and cross-app access with several identity vendors adopted within days of each other. Things which are still in draft are OAR 2.1 itself and an IETF proposal on agent authentication, co-written by engineers from Okta, Penny WZscaler, OpenAI, and De Facto. NIST is still working on it too. And the biggest gap which is still there is a standard for one agent safely handing work to another, which is still open. So where it is heading? Well, there are three bets. One, identity becomes a control plane for agents and decide what an agent can touch. Second, permissions move from roles to task. Not the payment agent can edit vendors, but it can update this one vendor record. For this invoice for next 10 minutes. Access born with the task gone when it ends. Third, agents will need passport, not just a badge, an identity any company can verify. So your agent can safely work with someone else's. That's where the next standard fight will be. Let me leave you with one final test. Pick any running agent in your company, imagine it took an action at 2 o'clock at night. Can you answer these four questions under a minute? Firstly, which agent was it? By its own name, not somebody's login. Who was it acting for? What was it allowed to do? And was that permission still supported to be alive? And if you had to, could you switch off? That one agent without switching off the person, if you can answer all four, your identity layer is ready for agents. If you cannot, that's your roadmap. Three decades ago, we figured out the way every employee needs a batch. 2026, the lesson is this: every agent needs one too with its own name, an owner behind it, an expiry date, and the next step after that batch probably is a passport. I'm Jascott, this is Tech Talk. See you in the next one.