CIO Influence Interview With Ralph Rodriguez, President & Chief Product Officer, Daon

Ralph Rodriguez, President & Chief Product Officer at Daon chats about the evolution of identity and access management in an AI driven era in this Q&A with CIO Influence:

________

Hi Ralph, tell us about your latest patent and more about your newest AI enhancements?

The newest patent is about controlling an AI agent at the moment it attempts to act, not merely authenticating a person at the beginning of a session.

U.S. Patent No. 12,688,261 addresses the authorization of a tool or API invocation by an autonomous AI agent. Traditional identity and access management (IAM) systems were designed around a person authenticating and then operating within a session. An agent has a different operating profile: it can plan, branch, call several tools, retry actions, and move at machine speed. A valid login therefore does not mean every later action should inherit broad authority.

Our patented approach introduces an authorization checkpoint for the requested action. The system can consider whether the agent remains connected to the person it is intended to represent, whether the agent and its runtime are behaving within expected bounds, and the context of the request; including the tool, action, resource, scope, nonce, and execution environment. When policy conditions are met, the system generates a machine-verifiable delegation artifact. We view it as narrowly written digital permission slip: it can specify the exact action, resource, scope, time window, invocation count, transaction limit, or side-effect limit that is allowed. It can also be bound to runtime evidence and protected against replay.

The important point is that this is not an enhancement intended to make an agent more intelligent whatsoever. It is an enhancement to make the authority used by the agent more controllable, attributable, and revocable. That is where the danger resides for unmanaged agents.

The patent is also part of a broader research progression for Daon. One earlier patent (US 12,452,035) addresses whether an agent remains faithfully linked to the intended person as behavioral patterns change. We enroll the human utilizing an IDV process and bind it to the AI agent. Our second patent (US 12,563,045) addresses the behavioral integrity of the agent and its runtime using execution signals and attestation. The latest issued patent turns those forms of trust, together with request context, into a decision about a specific action. The future commercial implementation is a separate engineering step, but the architectural direction is clear to Daon: identity, runtime integrity, policy, step-up approval, action-level authorization, and evidence need to work as one control system.

As AI innovations create more impact across industries, why should business adopters pay more attention to governance and trust layers? How can business heads stay better informed about which AI protocols are best suited to their team and workflows?

The governance problem changes when AI moves from generating content to taking actions that affect customers, money, data, entitlements, or regulated decisions.

A governance document or an approval committee is necessary, but it is not sufficient. The trust layer has to appear in the execution path. It should determine who or what is acting, on whose authority, what data and tools may be used, which side effects are permitted, when human approval is required, how authority expires or is revoked, and what evidence will exist afterward. Otherwise, organizations can have strong policy on paper and weak control(s) at the API or tool where the action actually occurs.

Business leaders should also resist the idea that there is one ‘best’ AI protocol. There is not as far as our research shows. Different protocols solve different parts of the architecture. Model Context Protocol (MCP) is designed to connect AI applications to external tools and data. Agent-to-Agent protocols address discovery and communication between agents across platforms. OAuth, OpenID Connect, credentials, certificates, and API-security controls remain relevant for identity and delegated access. None of these, by itself, answers the full business-governance question of an agentic AI.

The better approach is to start with the workflow and trust boundary. What action is the agent performing? Is it read-only, draft-only, reversible, or irreversible? Which data classes are involved? Can the agent delegate to another agent? Where is authority enforced? How quickly can it be revoked? What happens if a protocol endpoint, tool response, or agent runtime is compromised? The answers should drive the protocol choice, not the other way around. Deep thinking is involved, which is why there is so much FUD.

I would advise business heads to require a simple protocol scorecard covering interoperability, authorization granularity, identity binding, data minimization, human approval, revocation, audit evidence, security maturity, and exit portability. They should also insist that the organization separate protocol adapters from the governance layer. That reduces lock-in and allows an enterprise to support MCP, A2A, or future protocols without changing its core policy and evidence model each time the ecosystem moves.

Frameworks such as the NIST AI Risk Management Framework and OWASP’s agentic-security guidance can help leaders ask more disciplined questions. But the most practical starting point is still a narrow production scenario: permit low-risk, reversible work; keep high-impact actions behind fresh approval; and measure whether the system can fail safely.

Also Read: CIO Influence Interview with John Elliott, Cybersecurity Author Fellow at Pluralsight

How will traditional identity and access management (IAM) evolve with these new AI capabilities in the market?

Identity and access management (IAM) will evolve from authenticating a user and granting a session toward continuously governing the authority used by humans, agents, tools, and agent chains.

The familiar IAM questions; who are you, and what role do you have will remain important. But they are no longer enough. For an agentic workflow, the enterprise also needs to know: what is this agent, who owns or sponsors it, has it been enrolled according to a NIST 800-63-4 standard, which person or organization is it acting for, what purpose was approved, what runtime is it using, what action is it requesting, and what limits apply right now?

Agents should therefore become first-class non-human identities with lifecycle controls, accountable owners, approved purposes, registered runtimes, permitted tools, and explicit expiration or suspension states. Again, just like humans, but identity registration is only the starting point. Giving an agent the same long-lived entitlements as an employee or service account recreates standing privilege at machine speed. This given privilege matters!

The next generation of IAM will separate session authentication from action authorization. Sensitive actions should be governed with short-lived, purpose-bound authority that is specific to the tool, resource, scope, and time window. Policy should be able to allow, narrow, require step-up, sandbox, deny, or revoke. The tool or API that performs the protected action must validate that authority before execution; otherwise, the organization has visibility rather than enforcement.

IAM will also need to consume signals beyond credentials: device and session risk, transaction risk, agent behavior, runtime attestation, data sensitivity, and evidence of human approval. When agents delegate work to other agents, identity governance will have to preserve lineage and ensure that downstream authority does not become broader than the authority held by the parent agent. This is where Daon’s fourth pending patent is focused.

This will pull IAM closer to privileged access management, API security, fraud systems, data-loss prevention, SIEM, and agent-runtime monitoring. In effect, identity becomes the control plane that connects a human or enterprise principal to machine execution, with least privilege, continuous policy, revocation, and evidence.

Agentic AI for regulated industries: what matters most? What should security and data-trust teams do to build a more cohesive AI-automation-human connection around identity and trust?

For regulated industries, the central requirement is bounded authority with clear accountability: useful automation should be possible without allowing an agent to acquire durable or weakly attributable power.

Banks, insurers, healthcare organizations, telecommunications providers, and government agencies should begin by separating what an agent can prepare from what it can finally execute. An agent may be allowed to retrieve approved records, summarize a case, analyze a claim, or prepare a payment draft. Money movement, trade execution, identity changes, claim payment, benefit redirection, credential reset, or release of sensitive information should sit behind a separate policy decision and, where appropriate, fresh human approval. In simple terms, where can a transaction level authority hurt the organization?

Security and data-trust teams can build a more cohesive model by doing seven things:

1. Map the authority path. Document the human or enterprise principal, the agent, every tool and API, the data classes involved, the permitted side effects, and any downstream agents. Unmapped authority becomes unmanaged authority.
2. Register and bind agents to a purpose. Every production agent should have an enrolled IDV-based identity, an accountable owner, an approved business purpose, a lifecycle state, and a defined scope. An API key alone is not an adequate identity model.
3. Enforce policy at the point of action. Do not rely solely on a system prompt or a session token. The protected API, tool, or connector should validate action-specific authority before it changes data, moves value, or creates an external effect.
4. Minimize data and privilege. Use purpose limitation, least privilege, short validity windows, scoped data access, rate and transaction limits, and draft-only modes. An agent should receive only what it needs for the next action.
5. Design human intervention deliberately. Step-up approval should be risk-based, not triggered for every action. The goal is to preserve useful automation while reserving human authority for high-impact, unusual, or irreversible decisions. Human in the loop where it makes critical sense.
6. Build revocation and evidence from the start. Teams need to be able to stop an agent, invalidate its authority, preserve the decision trail, and answer who authorized what, for which agent, against which resource, and for how long.
7. Test the agent as an adversarial system. Production testing should include prompt injection, replay, tool-output manipulation, model or runtime substitution, excessive permissions, unsafe retries, data exfiltration, malicious subagents, and failures that occur across agent chains. Red teaming matters.

The governance model should be cross-functional. Product defines the customer outcome; security defines the control and threat model; identity teams establish principals and delegated authority; data teams govern provenance, minimization, and retention; legal and compliance define regulated boundaries; and operations prepare for exceptions and disputes. No single team can solve agentic trust in isolation. Cross-functional teams matter.

A useful way to measure readiness is this: a proof of concept (PoC) tests whether an agent can complete a task. Production tests whether the enterprise can control the authority the agent uses while completing that task. In regulated environments, production readiness should be judged not only by task success, but by whether the system can constrain, explain, revoke, and safely recover from the agent’s actions.

Catch more CIO Insights: How Are CIOs Aligning Technology with Workforce Agility?

[To share your insights with us, please write to psen@itechseries.com ]