AI agents are forcing banks, merchants, software vendors, and identity providers to extend Know Your Customer controls into Know Your Agent practices in 2026, because machines can now act for people across scheduling, support, payments, onboarding, and account-management workflows. The security problem is no longer just whether a login belongs to Alice. It is whether Alice’s authorized proxy is really acting for Alice, within the right limits, using data that deserves to be trusted.
That sounds like a niche compliance headache until you follow the chain of custody. A human delegates authority to an agent. The agent touches APIs, reads private data, triggers workflows, and may hand off tasks to other systems. Somewhere downstream, a merchant, bank, employer, or cloud service has to decide whether the action is legitimate automation or fraud wearing a productivity mask.
The payments industry has spent decades refining a simple premise: before you let someone open an account, move money, or access sensitive services, establish who they are. Know Your Customer, anti-money-laundering controls, device reputation, behavioral analytics, biometrics, and step-up authentication all grew around that human-centered assumption. Even when fraudsters used bots, the goal was usually to impersonate a person.
Agentic AI muddies that model because the “user” at the point of action may not be a person at all. It may be a Copilot-style assistant, a customer-service workflow, a budgeting agent, a procurement bot, or a model-driven process operating through a delegated token. The principal remains human or corporate, but the actor is software.
That distinction matters. Identity systems are good at asking whether a credential is valid. They are less mature at asking whether a machine presenting that credential is the expected machine, acting in the expected role, for the expected reason, with the expected level of supervision.
The PaymentsJournal discussion between Memoona Anwar of Data Zoo and Tracy Goldberg of Javelin Strategy & Research lands on the phrase that will likely become unavoidable: Know Your Agent. KYA is not a marketing flourish. It is an admission that agentic systems are creating a new class of identity subject, one that sits between human users, service accounts, bots, APIs, and regulated decision engines.
KYA starts from a more awkward premise. An agent does not have a birth date, a passport, a face, or a residential address. It has an owner, an issuer, a runtime environment, permissions, data sources, model behavior, logs, tool integrations, and a history of actions. Its “identity” is less like a person and more like a dossier assembled from provenance, authorization, behavior, and governance.
That is why Anwar’s framing is important. Trusting an agent is not really about trusting its intelligence. It is about trusting its identity, its authority, and the information it uses to act. A brilliant model with vague permissions and polluted data is not trustworthy; it is just a faster way to convert ambiguity into consequences.
For Windows and Microsoft 365 administrators, this should feel familiar and uncomfortable at the same time. Enterprises already manage service principals, OAuth grants, Entra ID applications, conditional access policies, delegated permissions, and privileged access workflows. Agentic AI does not replace that stack. It stretches it into a domain where natural-language instructions, probabilistic reasoning, and autonomous tool use collide with old assumptions about identity and access management.
Remote identity verification still assumes the subject is a human. It asks whether the applicant’s documents, device, biometrics, address, phone number, and behavioral traces cohere. Agent verification asks something else: who created this agent, who controls it, what can it do, what human or organization is it representing, and how can a relying party prove that link at the moment of action?
Goldberg’s point that agents will need digital footprints and behavioral patterns echoes the way fraud teams already think about humans. A user who always logs in from Ohio on one device and suddenly initiates a high-value transfer from a new session in another country will trigger scrutiny. An agent, too, will need a behavioral baseline.
But the baseline will be harder to interpret. Agents may operate continuously, invoke tools at machine speed, and behave differently as models are updated or prompts change. They may also be cloned, wrapped, impersonated, or manipulated through prompt injection. A stable behavioral identity for software that learns, delegates, and integrates with other software is not impossible, but it is not a solved compliance checkbox either.
If an agent is acting on stale, incomplete, fraudulent, or poorly governed data, its decisions can look confident while being wrong. In financial contexts, that can mean synthetic identities, mule accounts, fraudulent business onboarding, compromised credentials, or transactions that pass superficial checks because the agent’s inputs were manipulated upstream. The machine’s confidence is not evidence. The data trail is.
This is where KYA starts to resemble supply-chain security. Organizations must know where identity data came from, how it was collected, how often it is refreshed, whether it is legally usable, how it is matched, and how errors are corrected. Data Zoo’s emphasis on vendor and data-source due diligence fits squarely into this larger governance problem.
The Windows ecosystem has a parallel lesson here. Administrators learned the hard way that endpoint security is not just about malware signatures; it is about patch provenance, signed drivers, trusted update channels, least privilege, audit logs, and configuration drift. Agentic AI needs a similar discipline around identity data. The model is not the whole system. The system is the model plus data, permissions, workflow, telemetry, and accountability.
Scale is the obvious difference. A human fraudster can test a limited number of identity combinations, scripts, or account-opening strategies. Automated systems can do far more, and AI can make those attempts more adaptive. It can vary language, tune attacks to context, generate plausible documentation trails, and orchestrate probing across services without the same labor constraints.
The more subtle difference is abstraction. When an agent acts, the relying party may not see the human directly. The merchant or bank sees a transaction, a request, an API call, or a workflow event mediated by software. If something goes wrong, the incident response question becomes thornier: did the human intend this, did the agent misunderstand, did an attacker manipulate the agent, did a bad actor impersonate the agent, or did a compromised data source mislead it?
That ambiguity is where fraud thrives. Traditional controls often separate identity, authorization, and intent into different boxes. Agentic AI collapses them into one live decision. The identity may be valid, the token may be legitimate, and the action may still be outside the human’s real intent.
That gives Microsoft an advantage and a burden. The advantage is that enterprise identity, permissions, audit logging, and data governance already exist in the Microsoft stack. The burden is that agents inherit the messy reality of those environments: over-permissioned users, stale groups, overshared SharePoint sites, legacy OAuth grants, weak app consent practices, and data nobody has classified properly.
A Copilot agent that can read “everything the user can read” is only as safe as the user’s access graph. If the organization has spent years tolerating permission sprawl, the agent does not magically fix it. It accelerates discovery, synthesis, and action across the same sprawl.
That is why agent identity must be treated as a first-class security object, not a cute wrapper around an existing account. Administrators need to know which agents exist, who owns them, what triggers them, what data they can access, what actions they can take, and whether those actions are read-only, write-capable, financial, external, or irreversible. Without that inventory, “AI governance” is just a slide deck over an unmanaged attack surface.
Agents are more expressive than service accounts, but they can suffer from the same governance failures. They can accumulate permissions. They can outlive their original purpose. They can be created by business teams outside central IT. They can become critical infrastructure without being documented as such.
The difference is that agents may also make judgments. A service account usually executes a defined process. An agent may interpret a request, retrieve context, decide which tool to use, summarize evidence, and initiate an action. That means identity governance alone is insufficient. Organizations also need decision governance.
This is where the phrase least privilege needs an agentic sequel: least agency. An agent should not merely have the minimum access required; it should have the minimum autonomy required. The safest customer-support agent may be one that drafts a refund but cannot issue it. The safest finance agent may prepare a transfer but require human approval above a threshold. The safest HR agent may summarize policy but be barred from making eligibility decisions.
Not all agents deserve the same controls. A blanket ban on automation will fail because the productivity benefits are real and because business units will route around security teams that offer only “no.” A blanket embrace will fail because high-stakes workflows cannot be governed by enthusiasm.
The practical path is risk tiering. Low-risk agents can operate with broad usability and light supervision. Medium-risk agents need stronger logging, constrained tools, and clearer approval paths. High-risk agents need explicit human-in-the-loop controls, transaction limits, hardened identity proofing, independent data verification, and continuous monitoring.
Financial services already understands this logic. A bank does not treat checking an account balance like wiring a large sum to a new beneficiary. The same principle should apply to agents. The action defines the control burden.
“Allow this app to read your mail” was always a loaded sentence. “Allow this agent to reason over your mail, files, meetings, contacts, workflows, and third-party tools so it can complete goals on your behalf” is something else entirely. The user may understand the desired outcome while misunderstanding the permission surface.
Enterprises therefore need authorization models that are narrower, more contextual, and more revocable. Agents should be bound to scopes that reflect tasks, not vague access categories. They should expose what they plan to do before doing it, especially when the result is external, financial, destructive, or difficult to reverse.
This is not just user-interface design. It is evidence for later accountability. When an agent makes a decision, investigators need to reconstruct what authority it had, what data it saw, what instruction it followed, what tool it invoked, and whether the action matched policy. Without that chain, organizations will be left arguing with their own logs.
But in an agentic environment, prompt injection also becomes an identity and authorization issue. The attacker is not merely trying to make the model say something embarrassing. The attacker is trying to make a trusted agent act with delegated authority.
That changes the defensive posture. It is not enough to sanitize prompts or tune guardrails. Systems must assume that agents will encounter hostile content and must prevent untrusted input from becoming trusted instruction. The agent’s identity, tool permissions, memory, and execution path must remain separable from the data it reads.
This is familiar to anyone who has spent time with web security. We learned to distinguish code from data because SQL injection and cross-site scripting punished systems that blurred the line. Agentic AI is forcing a similar distinction: content retrieved for context must not silently become command authority.
That does not mean every token of model output needs to be stored forever. Privacy, cost, and security concerns make indiscriminate logging dangerous. But high-risk agent workflows need enough telemetry to answer basic questions after the fact. Who invoked the agent? What identity did it use? What data sources were queried? What tool calls were made? What policy checks fired? What human approvals occurred? What changed in the external world?
The audit log is not glamorous, but it may become the difference between manageable automation and regulatory chaos. If a bank cannot explain why an agent approved an account, or an enterprise cannot explain why an agent accessed sensitive files, trust erodes quickly. “The AI did it” is not a control narrative.
For WindowsForum readers, this has a practical implication: SIEM, XDR, identity governance, data-loss prevention, and audit-retention strategies need to evolve together. Agent activity should not live in a separate novelty console. It belongs in the same operational reality as privileged access, endpoint events, SaaS activity, and data movement.
Authoritative data reduces uncertainty. It helps bind an agent to a principal. It helps verify a customer or business. It helps detect synthetic identities. It helps distinguish a normal delegated action from a suspicious one. It helps determine whether the agent is acting from a trustworthy source of truth or a polluted approximation of reality.
This is why KYA will not be solved by model vendors alone. Identity providers, banks, data brokers, government sources, device-intelligence firms, fraud platforms, cloud vendors, and enterprise IT teams all sit in the trust chain. If any link is weak, the agent can inherit that weakness.
The hard part is that authoritative data is also politically and legally sensitive. More data can improve verification, but it can also increase surveillance, privacy exposure, and breach impact. Goldberg’s observation about siloed data and privacy constraints cuts both ways. The answer is not to pour every signal into one giant identity lake. The answer is to use better-governed signals for better-scoped decisions.
Financial institutions already have obligations around customer identification, AML controls, suspicious activity monitoring, vendor oversight, data protection, and model risk management. Agentic AI does not erase those duties. It creates a new implementation layer that examiners, auditors, and plaintiffs will eventually scrutinize.
That should worry organizations treating agents as productivity experiments rather than governed systems. A pilot that reads internal documents is one thing. A production agent that influences account decisions, payment flows, credit outcomes, fraud reviews, or customer communications is another.
The dividing line is not whether a system is called AI. It is whether it affects rights, money, access, security, or compliance. Once it does, “experimental” stops being a shield.
Security teams should resist the urge to begin with a policy memo nobody reads. Start with inventory. Which agents exist? Who created them? Which identities do they run under? Which connectors do they use? Which data repositories can they reach? Which actions can they perform? Which logs capture their behavior?
The next step is classification. A calendar assistant, a code-review bot, an expense-policy helper, and an account-onboarding agent do not belong in the same risk bucket. Classification should drive control selection, not the other way around.
Finally, organizations should make revocation easy. If an agent behaves unexpectedly, loses its business owner, changes purpose, or connects to a risky data source, administrators need the ability to suspend it without breaking half the company. The history of enterprise IT is full of systems nobody dares turn off. Agentic AI should not add another generation of immortal automation.
The trust boundary is moving from login to delegation. The key question becomes: what exactly did the user delegate, to whom, for how long, under what constraints, and with what visibility? A secure login followed by an overbroad delegation is still a security failure.
This shift will be especially difficult in consumer finance. People may welcome an agent that optimizes bills, negotiates subscriptions, monitors spending, or shops for better rates. But if that agent needs access to bank accounts, email receipts, credit products, or payment instruments, the authorization model must be understandable to non-experts.
Enterprise users face a related problem with higher blast radius. An employee may approve an agent to “help with procurement” without appreciating that it can access vendor records, contract drafts, approval chains, and payment workflows. In that world, usability and governance cannot be enemies. If safe delegation is too hard, unsafe delegation will win.
An agent will need a unique identity that can be authenticated. It will need an owner accountable for its behavior. It will need signed or otherwise verifiable provenance showing where it came from and whether it has been altered. It will need constrained permissions tied to tasks. It will need logs that distinguish human instruction, agent reasoning, tool calls, and external actions. It will need data-source validation. It will need policy checks that adapt to risk.
None of this is conceptually exotic. It is the convergence of identity governance, API security, software supply-chain assurance, fraud analytics, data governance, and AI risk management. The challenge is operational integration.
That integration will be hard because organizational boundaries are messy. Compliance may own KYC. Security may own identity and access management. Data teams may own source quality. Business units may own workflows. Legal may own consent and liability. Vendors may own the agent platform. KYA falls between all of them, which means it can easily become everybody’s concern and nobody’s job.
The trick is placing friction where it changes risk. Low-value, reversible, routine actions should feel easy. High-value, irreversible, unusual, or externally visible actions should slow down. If an agent schedules a meeting, let it work. If it changes bank details, moves money, grants access, deletes records, signs a contract, or sends sensitive data outside the tenant, make it prove the action deserves to happen.
This is where adaptive controls matter. A familiar agent performing a familiar task with familiar data should not be treated like a newly created agent invoking a new connector from an unusual location against a high-value workflow. Context is the control surface.
Well-designed friction also protects vendors. If agentic systems are allowed to operate with vague consent and broad authority, the first wave of high-profile failures will produce a backlash that slows adoption. Trust is not the enemy of deployment. Trust is what keeps deployment from becoming a liability story.
That sounds like a niche compliance headache until you follow the chain of custody. A human delegates authority to an agent. The agent touches APIs, reads private data, triggers workflows, and may hand off tasks to other systems. Somewhere downstream, a merchant, bank, employer, or cloud service has to decide whether the action is legitimate automation or fraud wearing a productivity mask.
The Next Identity Crisis Will Not Look Human
The payments industry has spent decades refining a simple premise: before you let someone open an account, move money, or access sensitive services, establish who they are. Know Your Customer, anti-money-laundering controls, device reputation, behavioral analytics, biometrics, and step-up authentication all grew around that human-centered assumption. Even when fraudsters used bots, the goal was usually to impersonate a person.Agentic AI muddies that model because the “user” at the point of action may not be a person at all. It may be a Copilot-style assistant, a customer-service workflow, a budgeting agent, a procurement bot, or a model-driven process operating through a delegated token. The principal remains human or corporate, but the actor is software.
That distinction matters. Identity systems are good at asking whether a credential is valid. They are less mature at asking whether a machine presenting that credential is the expected machine, acting in the expected role, for the expected reason, with the expected level of supervision.
The PaymentsJournal discussion between Memoona Anwar of Data Zoo and Tracy Goldberg of Javelin Strategy & Research lands on the phrase that will likely become unavoidable: Know Your Agent. KYA is not a marketing flourish. It is an admission that agentic systems are creating a new class of identity subject, one that sits between human users, service accounts, bots, APIs, and regulated decision engines.
KYC Was Built for People, Not Proxies With Tool Access
Traditional KYC works because it binds identity evidence to a human being. That evidence can include government records, phone data, address history, biometrics, document verification, sanctions screening, and account behavior. The process is imperfect, but the basic claim is intelligible: this person exists, this person is likely who they claim to be, and this person can be assessed against legal and risk obligations.KYA starts from a more awkward premise. An agent does not have a birth date, a passport, a face, or a residential address. It has an owner, an issuer, a runtime environment, permissions, data sources, model behavior, logs, tool integrations, and a history of actions. Its “identity” is less like a person and more like a dossier assembled from provenance, authorization, behavior, and governance.
That is why Anwar’s framing is important. Trusting an agent is not really about trusting its intelligence. It is about trusting its identity, its authority, and the information it uses to act. A brilliant model with vague permissions and polluted data is not trustworthy; it is just a faster way to convert ambiguity into consequences.
For Windows and Microsoft 365 administrators, this should feel familiar and uncomfortable at the same time. Enterprises already manage service principals, OAuth grants, Entra ID applications, conditional access policies, delegated permissions, and privileged access workflows. Agentic AI does not replace that stack. It stretches it into a domain where natural-language instructions, probabilistic reasoning, and autonomous tool use collide with old assumptions about identity and access management.
The Pandemic Taught Remote Verification; Agents Break the Next Assumption
The pandemic era accelerated remote onboarding, digital document checks, liveness detection, behavioral signals, and non-face-to-face identity proofing. Financial institutions and digital platforms learned how to make higher-stakes decisions without a person standing at a branch counter. That history is useful, but it does not solve the agent problem.Remote identity verification still assumes the subject is a human. It asks whether the applicant’s documents, device, biometrics, address, phone number, and behavioral traces cohere. Agent verification asks something else: who created this agent, who controls it, what can it do, what human or organization is it representing, and how can a relying party prove that link at the moment of action?
Goldberg’s point that agents will need digital footprints and behavioral patterns echoes the way fraud teams already think about humans. A user who always logs in from Ohio on one device and suddenly initiates a high-value transfer from a new session in another country will trigger scrutiny. An agent, too, will need a behavioral baseline.
But the baseline will be harder to interpret. Agents may operate continuously, invoke tools at machine speed, and behave differently as models are updated or prompts change. They may also be cloned, wrapped, impersonated, or manipulated through prompt injection. A stable behavioral identity for software that learns, delegates, and integrates with other software is not impossible, but it is not a solved compliance checkbox either.
The Agent Is Only as Trustworthy as Its Data Supply Chain
The most underrated line in the PaymentsJournal conversation is the emphasis on authoritative data. AI security debates often rush toward model behavior, prompt injection, jailbreaks, and hallucination. Those are real risks, but identity verification lives or dies on data provenance.If an agent is acting on stale, incomplete, fraudulent, or poorly governed data, its decisions can look confident while being wrong. In financial contexts, that can mean synthetic identities, mule accounts, fraudulent business onboarding, compromised credentials, or transactions that pass superficial checks because the agent’s inputs were manipulated upstream. The machine’s confidence is not evidence. The data trail is.
This is where KYA starts to resemble supply-chain security. Organizations must know where identity data came from, how it was collected, how often it is refreshed, whether it is legally usable, how it is matched, and how errors are corrected. Data Zoo’s emphasis on vendor and data-source due diligence fits squarely into this larger governance problem.
The Windows ecosystem has a parallel lesson here. Administrators learned the hard way that endpoint security is not just about malware signatures; it is about patch provenance, signed drivers, trusted update channels, least privilege, audit logs, and configuration drift. Agentic AI needs a similar discipline around identity data. The model is not the whole system. The system is the model plus data, permissions, workflow, telemetry, and accountability.
AI Does Not Invent Fraud; It Industrializes It
One useful corrective in the webinar is that AI agents do not create an entirely new fraud universe. Credential stuffing, bot attacks, identity probing, phishing, account takeover, and synthetic identity fraud already existed. AI changes the economics.Scale is the obvious difference. A human fraudster can test a limited number of identity combinations, scripts, or account-opening strategies. Automated systems can do far more, and AI can make those attempts more adaptive. It can vary language, tune attacks to context, generate plausible documentation trails, and orchestrate probing across services without the same labor constraints.
The more subtle difference is abstraction. When an agent acts, the relying party may not see the human directly. The merchant or bank sees a transaction, a request, an API call, or a workflow event mediated by software. If something goes wrong, the incident response question becomes thornier: did the human intend this, did the agent misunderstand, did an attacker manipulate the agent, did a bad actor impersonate the agent, or did a compromised data source mislead it?
That ambiguity is where fraud thrives. Traditional controls often separate identity, authorization, and intent into different boxes. Agentic AI collapses them into one live decision. The identity may be valid, the token may be legitimate, and the action may still be outside the human’s real intent.
Microsoft’s Agent Push Makes This a Windows Admin Problem
This debate is not confined to fintech. Microsoft has spent the last several years weaving Copilot into Windows, Microsoft 365, security operations, developer tools, and business workflows. Copilot Studio and Microsoft 365 Copilot agents make the agent model increasingly normal inside organizations that already run on Entra ID, SharePoint, Teams, Exchange, Defender, and Power Platform.That gives Microsoft an advantage and a burden. The advantage is that enterprise identity, permissions, audit logging, and data governance already exist in the Microsoft stack. The burden is that agents inherit the messy reality of those environments: over-permissioned users, stale groups, overshared SharePoint sites, legacy OAuth grants, weak app consent practices, and data nobody has classified properly.
A Copilot agent that can read “everything the user can read” is only as safe as the user’s access graph. If the organization has spent years tolerating permission sprawl, the agent does not magically fix it. It accelerates discovery, synthesis, and action across the same sprawl.
That is why agent identity must be treated as a first-class security object, not a cute wrapper around an existing account. Administrators need to know which agents exist, who owns them, what triggers them, what data they can access, what actions they can take, and whether those actions are read-only, write-capable, financial, external, or irreversible. Without that inventory, “AI governance” is just a slide deck over an unmanaged attack surface.
The Old Service Account Problem Returns Wearing a Suit
Every sysadmin knows the service account anti-pattern. A workflow needs access, someone creates an account, grants broad permissions, hardcodes a secret, forgets to rotate it, and years later nobody knows what breaks if it is disabled. Agentic AI risks repeating that history at a higher level of abstraction.Agents are more expressive than service accounts, but they can suffer from the same governance failures. They can accumulate permissions. They can outlive their original purpose. They can be created by business teams outside central IT. They can become critical infrastructure without being documented as such.
The difference is that agents may also make judgments. A service account usually executes a defined process. An agent may interpret a request, retrieve context, decide which tool to use, summarize evidence, and initiate an action. That means identity governance alone is insufficient. Organizations also need decision governance.
This is where the phrase least privilege needs an agentic sequel: least agency. An agent should not merely have the minimum access required; it should have the minimum autonomy required. The safest customer-support agent may be one that drafts a refund but cannot issue it. The safest finance agent may prepare a transfer but require human approval above a threshold. The safest HR agent may summarize policy but be barred from making eligibility decisions.
Risk Tiers Matter More Than AI Hype
Anwar’s scheduling-versus-funds-transfer contrast is the right mental model. If an AI assistant mangles a calendar invite, the consequence is annoyance. If it onboards a fraudulent business, releases funds, approves a vendor, changes payroll details, or exposes regulated data, the consequence can be financial loss, privacy breach, compliance failure, and reputational damage.Not all agents deserve the same controls. A blanket ban on automation will fail because the productivity benefits are real and because business units will route around security teams that offer only “no.” A blanket embrace will fail because high-stakes workflows cannot be governed by enthusiasm.
The practical path is risk tiering. Low-risk agents can operate with broad usability and light supervision. Medium-risk agents need stronger logging, constrained tools, and clearer approval paths. High-risk agents need explicit human-in-the-loop controls, transaction limits, hardened identity proofing, independent data verification, and continuous monitoring.
Financial services already understands this logic. A bank does not treat checking an account balance like wiring a large sum to a new beneficiary. The same principle should apply to agents. The action defines the control burden.
Authorization Must Become More Specific Than Consent
OAuth consent screens and enterprise app approvals were already difficult for ordinary users to understand. Agentic AI makes consent even more fragile. A user may authorize an agent for a benign task without grasping the downstream implications of tool access, data retrieval, or chained actions.“Allow this app to read your mail” was always a loaded sentence. “Allow this agent to reason over your mail, files, meetings, contacts, workflows, and third-party tools so it can complete goals on your behalf” is something else entirely. The user may understand the desired outcome while misunderstanding the permission surface.
Enterprises therefore need authorization models that are narrower, more contextual, and more revocable. Agents should be bound to scopes that reflect tasks, not vague access categories. They should expose what they plan to do before doing it, especially when the result is external, financial, destructive, or difficult to reverse.
This is not just user-interface design. It is evidence for later accountability. When an agent makes a decision, investigators need to reconstruct what authority it had, what data it saw, what instruction it followed, what tool it invoked, and whether the action matched policy. Without that chain, organizations will be left arguing with their own logs.
Prompt Injection Is an Identity Problem in Disguise
The security community often treats prompt injection as a model-behavior issue, and that is partly true. Malicious instructions can be hidden in documents, web pages, emails, tickets, or other content that an AI system consumes. If the model follows those instructions, it may leak data, ignore policy, or misuse tools.But in an agentic environment, prompt injection also becomes an identity and authorization issue. The attacker is not merely trying to make the model say something embarrassing. The attacker is trying to make a trusted agent act with delegated authority.
That changes the defensive posture. It is not enough to sanitize prompts or tune guardrails. Systems must assume that agents will encounter hostile content and must prevent untrusted input from becoming trusted instruction. The agent’s identity, tool permissions, memory, and execution path must remain separable from the data it reads.
This is familiar to anyone who has spent time with web security. We learned to distinguish code from data because SQL injection and cross-site scripting punished systems that blurred the line. Agentic AI is forcing a similar distinction: content retrieved for context must not silently become command authority.
The Audit Log Becomes the New Witness
In disputes involving human users, organizations can lean on authentication records, device fingerprints, IP addresses, session histories, transaction confirmations, and customer communications. With agents, logs must do more. They must explain a chain of machine-mediated reasoning and action.That does not mean every token of model output needs to be stored forever. Privacy, cost, and security concerns make indiscriminate logging dangerous. But high-risk agent workflows need enough telemetry to answer basic questions after the fact. Who invoked the agent? What identity did it use? What data sources were queried? What tool calls were made? What policy checks fired? What human approvals occurred? What changed in the external world?
The audit log is not glamorous, but it may become the difference between manageable automation and regulatory chaos. If a bank cannot explain why an agent approved an account, or an enterprise cannot explain why an agent accessed sensitive files, trust erodes quickly. “The AI did it” is not a control narrative.
For WindowsForum readers, this has a practical implication: SIEM, XDR, identity governance, data-loss prevention, and audit-retention strategies need to evolve together. Agent activity should not live in a separate novelty console. It belongs in the same operational reality as privileged access, endpoint events, SaaS activity, and data movement.
Authoritative Data Is the Boring Control That Wins
AI coverage tends to reward dramatic examples: rogue chatbots, jailbreaks, synthetic media, autonomous hackers, and science-fiction scenarios. The more durable security story is less theatrical. Organizations need better data hygiene.Authoritative data reduces uncertainty. It helps bind an agent to a principal. It helps verify a customer or business. It helps detect synthetic identities. It helps distinguish a normal delegated action from a suspicious one. It helps determine whether the agent is acting from a trustworthy source of truth or a polluted approximation of reality.
This is why KYA will not be solved by model vendors alone. Identity providers, banks, data brokers, government sources, device-intelligence firms, fraud platforms, cloud vendors, and enterprise IT teams all sit in the trust chain. If any link is weak, the agent can inherit that weakness.
The hard part is that authoritative data is also politically and legally sensitive. More data can improve verification, but it can also increase surveillance, privacy exposure, and breach impact. Goldberg’s observation about siloed data and privacy constraints cuts both ways. The answer is not to pour every signal into one giant identity lake. The answer is to use better-governed signals for better-scoped decisions.
Regulators Will Care About Outcomes, Not Terminology
The phrase Know Your Agent may be new, but regulators will not need a new philosophical category to intervene. If an AI-driven workflow enables fraud, violates sanctions controls, discriminates in onboarding, mishandles personal data, or obscures accountability, existing regulatory expectations can attach quickly.Financial institutions already have obligations around customer identification, AML controls, suspicious activity monitoring, vendor oversight, data protection, and model risk management. Agentic AI does not erase those duties. It creates a new implementation layer that examiners, auditors, and plaintiffs will eventually scrutinize.
That should worry organizations treating agents as productivity experiments rather than governed systems. A pilot that reads internal documents is one thing. A production agent that influences account decisions, payment flows, credit outcomes, fraud reviews, or customer communications is another.
The dividing line is not whether a system is called AI. It is whether it affects rights, money, access, security, or compliance. Once it does, “experimental” stops being a shield.
Windows Shops Should Start With Inventory, Not Philosophy
The immediate work is not to invent a grand theory of machine personhood. It is to find the agents and agent-like workflows already appearing inside the environment. Some will be official deployments. Others will be Power Platform automations, Copilot Studio experiments, browser-based AI tools, SaaS assistants, help-desk integrations, developer agents, or vendor-managed features quietly added to existing products.Security teams should resist the urge to begin with a policy memo nobody reads. Start with inventory. Which agents exist? Who created them? Which identities do they run under? Which connectors do they use? Which data repositories can they reach? Which actions can they perform? Which logs capture their behavior?
The next step is classification. A calendar assistant, a code-review bot, an expense-policy helper, and an account-onboarding agent do not belong in the same risk bucket. Classification should drive control selection, not the other way around.
Finally, organizations should make revocation easy. If an agent behaves unexpectedly, loses its business owner, changes purpose, or connects to a risky data source, administrators need the ability to suspend it without breaking half the company. The history of enterprise IT is full of systems nobody dares turn off. Agentic AI should not add another generation of immortal automation.
The Trust Boundary Moves From Login to Delegation
For years, security awareness training has told users to protect passwords, beware phishing, and approve MFA prompts only when they initiated the login. That advice remains necessary, but it is no longer sufficient. Users will increasingly authorize agents that persist beyond a single session and act across multiple services.The trust boundary is moving from login to delegation. The key question becomes: what exactly did the user delegate, to whom, for how long, under what constraints, and with what visibility? A secure login followed by an overbroad delegation is still a security failure.
This shift will be especially difficult in consumer finance. People may welcome an agent that optimizes bills, negotiates subscriptions, monitors spending, or shops for better rates. But if that agent needs access to bank accounts, email receipts, credit products, or payment instruments, the authorization model must be understandable to non-experts.
Enterprise users face a related problem with higher blast radius. An employee may approve an agent to “help with procurement” without appreciating that it can access vendor records, contract drafts, approval chains, and payment workflows. In that world, usability and governance cannot be enemies. If safe delegation is too hard, unsafe delegation will win.
The Practical Shape of KYA Is Already Emerging
The industry does not yet have a complete KYA standard, and Anwar is right that agents lack the mature footprints and verification mechanisms humans have accumulated online. But the ingredients are visible.An agent will need a unique identity that can be authenticated. It will need an owner accountable for its behavior. It will need signed or otherwise verifiable provenance showing where it came from and whether it has been altered. It will need constrained permissions tied to tasks. It will need logs that distinguish human instruction, agent reasoning, tool calls, and external actions. It will need data-source validation. It will need policy checks that adapt to risk.
None of this is conceptually exotic. It is the convergence of identity governance, API security, software supply-chain assurance, fraud analytics, data governance, and AI risk management. The challenge is operational integration.
That integration will be hard because organizational boundaries are messy. Compliance may own KYC. Security may own identity and access management. Data teams may own source quality. Business units may own workflows. Legal may own consent and liability. Vendors may own the agent platform. KYA falls between all of them, which means it can easily become everybody’s concern and nobody’s job.
The Agent Economy Needs Friction in the Right Places
The technology industry often treats friction as failure. Faster onboarding, fewer clicks, invisible authentication, and seamless automation are usually seen as signs of maturity. Security professionals know better. Some friction is not a bug; it is a control.The trick is placing friction where it changes risk. Low-value, reversible, routine actions should feel easy. High-value, irreversible, unusual, or externally visible actions should slow down. If an agent schedules a meeting, let it work. If it changes bank details, moves money, grants access, deletes records, signs a contract, or sends sensitive data outside the tenant, make it prove the action deserves to happen.
This is where adaptive controls matter. A familiar agent performing a familiar task with familiar data should not be treated like a newly created agent invoking a new connector from an unusual location against a high-value workflow. Context is the control surface.
Well-designed friction also protects vendors. If agentic systems are allowed to operate with vague consent and broad authority, the first wave of high-profile failures will produce a backlash that slows adoption. Trust is not the enemy of deployment. Trust is what keeps deployment from becoming a liability story.
The Security Lesson Hiding Inside the Webinar
The PaymentsJournal conversation is nominally about identity verification in payments, but its implications reach across the Windows and enterprise software landscape.- Organizations should treat agents as distinct actors with identities, owners, permissions, data dependencies, and audit trails.
- KYA should complement KYC by verifying the link between the human or business principal and the machine acting on its behalf.
- Agent risk should be tiered by the consequences of the action, not by the novelty of the technology.
- Authoritative data and vendor due diligence are foundational controls because agents inherit the quality and integrity of their inputs.
- Administrators should prioritize inventory, least privilege, least agency, logging, and revocation before expanding agent autonomy.
- High-stakes workflows should require stronger verification of identity, intent, authorization, and data provenance than low-stakes productivity tasks.
References
- Primary source: PaymentsJournal
Published: 2026-06-29T13:50:12.917810
Loading…
www.paymentsjournal.com - Related coverage: owasp.org
Loading…
owasp.org - Related coverage: breachcraft.io
Loading…
breachcraft.io - Official source: learn.microsoft.com
Loading…
learn.microsoft.com - Official source: csrc.nist.gov
- Related coverage: techradar.com
Experts warn Microsoft Copilot Studio agents are being hijacked to steal OAuth tokens
Microsoft acknowledges the risk, so users should be cautiouswww.techradar.com
- Related coverage: labs.cloudsecurityalliance.org
Loading…
labs.cloudsecurityalliance.org