Point of view - Foundations First, Part 1 - By Ed Goff - September 2026

The Last Mile Identity Problem in Agentic AI

The first in a series on the foundational work that makes AI adoption succeed.

Over ten days in September, I joined four very different conversations about AI:

• CDO BFSI Exchange USA, Charlotte (September 15-16): an invitation-only gathering of chief data officers and data leaders from banking, financial services, and insurance
• Oracle AI Experience, Charlotte (September 17): Oracle customers and enterprise practitioners exploring agentic AI adoption at scale
• Cybersecurity at Duke 2026, Durham (September 18): security leaders and practitioners, under the theme "Cybersecurity in the Age of Autonomy"
• Oracle Generative AI Workshop, Raleigh Founded (September 24): small founders sharing what they've built with AI and what's getting in their way

The rooms could hardly have been more different: regulated financial institutions, large enterprises, security practitioners, and early-stage startups. So were the people in them, from those new to AI to those who have worked in the field for years. Yet the underlying story was remarkably consistent. Everyone is struggling with the same three fundamentals: data, identity, and business processes.

What these conversations confirmed

At the CDO BFSI Exchange, data leaders kept returning to three questions: Is our data ready for AI? How will agent identity and access work? How do we observe and monitor what agents actually do? Several solution providers shared promising approaches, but the questions themselves were the signal.

At Oracle AI Experience, the foundations discussion was organized around three areas: tiered data controls, least privilege, and SDLC foundations. One comment stuck with me: prototypes and demos are easy, but making agents work at scale takes enterprise-grade governance and security. The recommended pattern was to start agents with minimal access, then open it up and iterate. When the conversation turned to getting engineers to build security in up front, the answers were practical: don't rely on prompts for security, enforce controls at every layer starting with the data, and shift left so security teams can see and collaborate with developers earlier. The hands-on labs, where we built agents using vector search, RAG, and graph relationships, also surfaced a phrase I expect to borrow: data chaos, meaning inconsistent data, fragmented data, and operational complexity.

At Cybersecurity at Duke, a speaker from OpenAI described how the pace of AI research has compressed from years to months to weeks. A speaker from Palo Alto Networks focused on fragmented security tools that need to work together, pointing to guidance from OWASP, Palo Alto Networks, and IBM for building security that enables the business. His core message: most attacks are preventable, and lack of visibility is the real problem. Much is logged, but little is alerted on. The answer is strong IAM that empowers the security operations center.

At the Raleigh Founded workshop, early-stage founders showing what they'd built with AI described the same struggles from the other end of the scale: smaller teams and fewer systems, but the same foundational gaps.

These problems can't be fixed with AI. Many of them existed long before anyone started deploying agents, and they have little to do with AI adoption itself. What AI does is put a spotlight on them. An agent that acts on your behalf is only as trustworthy as the data it reads, the identity it carries, and the processes it touches. That is where much of the real work lies right now in enabling AI programs to deliver value.

This series is my attempt to make sense of what I've been hearing. Each piece takes one of these foundational areas and looks at the practices and architectures that help organizations realize the value of AI while managing the risk and governance that come with it. The perspective is my own, shaped by candid feedback from many smart people across companies of different sizes and industries, each at a different point in the journey.

I'm starting with identity, because it offers one of the clearest examples of how agentic AI exposes gaps that were already there.

Where identity breaks: the last mile

Follow a single request through an agentic system and identity looks solid for most of the trip. A user signs in, a chat application passes the request to an AI agent, and the agent reaches enterprise tools through an MCP server. Every hop knows who asked.

Then the agent touches the systems that actually run the business: the ERP, the customer database, the claims platform. Those systems were built for applications, not agents. They typically accept an API key or a shared service account, and that credential says nothing about the person behind the request. IBM's Grant Miller calls this the "last mile" problem, and the name fits. The diagram below is my interpretation of it.

At that last hop, four things disappear:

• Who is asking
• What they intend to do
• The context around the request
• The delegation: that an agent is acting on someone's behalf, and within what limits

The back end sees a trusted application making a call. It cannot tell a legitimate request from a hijacked agent, an agent chaining tools it was never meant to combine, or a rogue agent posing as a good one. Zero trust holds everywhere except the place where the data and the transactions live.

This isn't a theoretical gap. In a 2026 Cloud Security Alliance survey, more than two-thirds of organizations said they can't clearly distinguish AI agent actions from human actions.

Why this is a foundations problem, not an AI problem

Nothing in that picture was created by AI. Shared service accounts, API keys embedded in code, and credentials that never expire are identity debt most organizations have carried for years. They were tolerable because traditional applications are predictable: they do a fixed set of things in a fixed order, so a broad credential carried limited risk.

Agents change that math. They decide at runtime which tools to call and in what sequence, they can be steered by content they read, and they act at machine speed. The same shortcut that was acceptable for a nightly batch job becomes a risk amplifier when an autonomous system inherits it.

This is also why company size doesn't protect anyone. A large enterprise has decades of legacy integrations to untangle. A startup may have only a handful of systems, but often wires its agent to them with a single powerful API key. The scale differs; the gap is the same.

The breach data backs this up. In Palo Alto Networks' Unit 42 2026 Global Incident Response Report, based on more than 750 incidents, identity weaknesses were exploited in 89% of investigations, and 90% of data breaches traced to misconfigurations or security gaps rather than advanced tradecraft. Agents didn't create those gaps. They will inherit them.

How I'd approach it

The fix isn't a smarter model. It's an identity architecture that carries the user's context all the way to the last hop. The four moves below are how I'd approach it, and they reflect where the major guidance is converging: the OWASP Top 10 for Agentic Applications, IBM's Architecting Secure Enterprise AI Agents with MCP, and the Cloud Security Alliance's Agentic AI Identity and Access Management framework.

1. Give every agent its own identity. Agents are nonhuman identities and deserve the same rigor as people: unique credentials, no sharing, and a clear owner. When something goes wrong, you need to know which agent did it and for whom. OWASP ranks identity and privilege abuse among the top agentic risks, and CSA calls non-human identity governance the defining security gap of the agentic era.
2. Put a broker in the path. Agents should never hold standing credentials to back-end systems. A vault or credential broker sits between the agent and legacy systems, verifies who is asking and on whose behalf, and issues short-lived, narrowly scoped credentials just in time. An agent that can't prove its identity and delegation doesn't get through.
3. Decide with policy, not just roles. Attribute- and policy-based access controls (ABAC/PBAC) let the back end weigh the user, the agent, the action, and the context of each request, instead of trusting whatever the credential allows. This context-aware, adaptive access is at the center of CSA's framework. Security can't live in the prompt; it has to be enforced at every layer, starting with the data.
4. Watch, learn, and tighten. Log agent activity in a form that can't be altered, alert on it (logging without alerting is one of the most common gaps), feed that telemetry back into policy, and keep a human in the loop, with a kill switch, for high-impact actions. Permissions should narrow over time as you learn what agents actually need.

A practical place to start, and one that runs alongside AI programs rather than ahead of them: inventory the API keys and service accounts your agents can reach today. Launch new agents with minimal access, then open permissions up as you learn what they need. Pick one high-value workflow and route it through a broker end to end. That single path will surface most of the policy, data, and process questions the rest of the program will face.

The bigger takeaway

None of this is solved by a better model. It's identity architecture, access policy, and credential management: foundational disciplines that organizations must mature regardless of AI. Whether it's a global bank or a three-person startup, the organizations that invest in these foundations won't just adopt AI more safely. They'll adopt it faster.

Back to Writing