Karina Portugal is Director of Banking, Marketplaces, Strategic Partnerships and Agentic Trust at Prove Identity. She works with major banks, fintechs and marketplaces in the United States, Brazil and Latin America, at the intersection of digital identity, fraud, artificial intelligence and business strategy. She has more than ten years in enterprise financial services, specialising in fraud prevention, AML, KYC and digital identity. Her current title includes Agentic Trust, and we spoke with her about what happens to identity infrastructure when the party initiating a transaction is a piece of software.
Agentic commerce is moving quickly. What breaks first?
Static trust breaks first. Attribution is the casualty. Every identity system in production today was built to answer one question: is this person who they claim to be. That question assumes a human at the other end, and it assumes the moment of verification and the moment of action are close enough together to treat as the same event. An agent breaks both assumptions. It acts later, it acts repeatedly, and it acts while the person is asleep. You can verify the human perfectly and still have no idea whether the transaction in front of you reflects what that human wanted.
Is that not solved by existing authorization standards?
Partially, and the parts that are solved are the easy parts. Delegated access between systems is well understood. What is not solved is delegation with commercial consequence and no human in the loop at the moment of execution. If an agent spends money on my behalf, three things have to be provable after the fact: that the agent was genuinely acting for me, that it stayed inside limits I actually set, and that the limits themselves were recorded in a way neither side can rewrite later. Today most of that evidence lives in application logs, which is to say it lives wherever the losing party in a dispute does not want it to live. The shape of the answer is continuous trust: authority scoped to a task, credentials that are short-lived rather than standing, context passed at the protocol level, and verification that has to hold at every layer and on every action rather than once at the bottom of the stack.
Financial institutions tend to respond to this by slowing down. Is that the right instinct?
It is the honest instinct, but it does not survive contact with the market. Customers are already using agents. If a bank refuses to accommodate that, the agent does not disappear, it just impersonates a browser and the bank loses all visibility into what is happening. The safest position is not refusal, it is making agent activity legible. An institution that can tell the difference between a customer, an agent working for that customer, and a bot attacking the account is in a far better position than one that treats all three as the same traffic.
What does that mean in practice for a risk team?
It means Know Your Agent as a discipline of its own, and a third category in the model. Most fraud systems today are binary: legitimate or not. Agent traffic is legitimate and non-human at the same time, and it behaves nothing like a person. It is fast, it is consistent, it does not hesitate, it does not mistype. Every behavioral signal that risk teams rely on to detect humans reads as anomalous when an agent is doing exactly what it was asked to do. If you do not build the third category deliberately, your model will keep flagging your best customers. And the harder case is the compromised one, because an agent that has been hijacked does not look hijacked. It carries valid credentials and it behaves like software. What changes is the scope of what it starts doing, which is why behavioral verification against the task it was authorized for matters more than the credential it presents.
Where does that leave the one-time passcode?
Where it has always been, which is as a message that proves a code arrived somewhere. It does not prove the number belongs to the person using it, and it does not survive SIM swap, porting or a customer being talked into reading the code out loud. The signals that hold up are phone-centric: bound to the number itself and to possession of the device, how long that number has been with that person, whether anything changed recently, whether the device in the session is the device it should be. The industry spent years treating verification as an event. It has to be a state.
What does delegation have to look like for this to work?
It has to be narrow, it has to expire, and it has to be re-checked rather than assumed. Most systems today grant an agent a standing credential at deployment and never revisit it, which means the authorization is describing a decision made weeks ago about a task that has since changed. What works instead is authority scoped to a specific task, credentials that are short-lived rather than permanent, and authorization that is re-evaluated at the moment of the action rather than at the start of the session. The point is not to put a human back in the loop at every step. It is to make the limits machine-checkable so you do not need to.
What should institutions be doing in the next twelve months?
Three things, and none of them require waiting for a standard. Decide internally what an agent is allowed to do on a customer’s behalf, in writing, before a product team decides it for you. Make sure your systems can record delegation in a form you could show a regulator or a court. And start distinguishing agent traffic from human traffic in your data now, even if you do nothing with the distinction yet, because you cannot build a model later on data you did not collect.
Where does the standardization eventually come from?
Probably not from a committee, at least not first. It usually starts with a few large institutions and a few infrastructure providers converging on something that works, and the formal standard arrives afterwards to describe what already happened. That is roughly how phone-based identity signals became normal. The practical implication is that the organizations experimenting now will have a disproportionate influence on what everyone else has to implement in three years.
Is there a risk of the industry over-engineering this?
There is a risk of the industry doing what it did with early two-factor authentication, which is adding friction in the wrong place and calling it security. If proving that an agent has authority requires the customer to intervene every time, nobody will use it and the agents will route around it. The design constraint is that verification has to be strong and almost entirely invisible. That is a harder engineering problem than it sounds, and it is where most of the interesting work is right now.
What keeps your attention on this problem specifically?
The fact that it is genuinely unsettled. I spend a lot of time with early adopters who are building these systems before there is a playbook, and with founders and investors in San Francisco, Palo Alto and New York who are working on it from the other direction. Being close to that is how you learn what the real constraints are rather than the ones in the marketing material. Identity has quietly become the control point for how digital commerce works. Getting it right for machines is going to matter more than most institutions currently assume.
About Karina Portugal
Karina Portugal is Director of Banking, Marketplaces, Strategic Partnerships and Agentic Trust at Prove Identity, working with major banks, fintechs and marketplaces in the United States, Brazil and Latin America
