Agent Identity and Delegated Authority for Risk Managers

Autonomous agents stopped being a lab experiment sometime in the last eighteen months. They now book travel, adjust pricing, reconcile invoices, write code, and answer customers without a human reading every step. That shift changes what governance has to do. When software only answered questions, the worst outcome was a bad answer. When software takes actions on your systems, the worst outcome is a wrong action nobody can trace back to a decision, an owner, or a reason.

This is why agent identity and delegated authority have quietly become the two most important words in AI governance this year. Not model accuracy. Not hallucination rates. Identity and delegation, because they determine whether an autonomous action can be attributed, authorized, and reversed. Get those two things wrong and every other control you have built, your risk taxonomy, your model cards, your ethics committee, sits on top of a foundation that cannot actually tell you who did what.

The good news is that none of this requires a computer science degree to understand or to govern well. The concepts map cleanly onto ideas risk and compliance professionals already know: badges, job descriptions, approval limits, and audit trails. What follows is a practical walk through what agent identity and delegated authority mean for your business, how the new NIST AI Agent Standards Initiative is shaping the rules of the road, where autonomous agents actually break in practice, and what to do about all of it starting Monday morning.

What agent identity actually means for your business

Think about how you onboard a new employee. They get a badge tied to their name, a manager who is accountable for their work, a job description that limits what they are expected to do, and an access profile that expires or gets reviewed. Nobody hands a new hire the master keys to the building and hopes for the best. Agent identity is the same idea, applied to software that now acts with a level of independence that used to require a human in the chair.

An agent’s identity has to be separate from the identity of the human who deployed it and separate from the application it lives inside. That distinction sounds technical, but the business reason is simple. If an agent shares a login or an API key with the app it runs in, or with the employee who set it up, you cannot answer the most basic question a regulator, an auditor, or a plaintiff’s lawyer will ask after something goes wrong: who, or what, actually took this action. Shared credentials collapse attribution. And you cannot govern what you cannot attribute.

Practitioner literature on agent design, including the widely read book on agentic artificial intelligence by Pascal Bornet and coauthors, converges on three things every agent needs before it is allowed to touch a real system. A purpose, meaning a plain statement of why this agent exists and what problem it solves. A role, meaning the persona and domain it operates in, a tax assistant behaves differently than a customer support agent, and that difference should be designed in rather than discovered later. And a scope, meaning an explicit, written boundary of what the agent may do and, just as importantly, what it must never do. An agent without a documented scope is not autonomous, it is unsupervised, and those are different things with very different liability profiles.

The practical failure pattern shows up constantly in early agent deployments. A business unit spins up an agent using a shared service account because provisioning a real identity takes an extra ticket. The agent works, gets extended to a second task, then a third, and within a quarter it has more access than anyone remembers granting and no single person can say who owns it. This is what practitioners now call a shadow agent, and it is the AI-era version of shadow IT, except this shadow system can act on its own.

The fix is not exotic. Every agent your organization runs needs a named human owner, a recorded creation event, and a documented link to the exact role or credential set it operates under. That is the entire test. If you cannot produce those three facts for an agent in under a minute, you do not control that agent, you are hosting it.

How delegated authority breaks without clear boundaries

Delegation is an old idea with a new set of consequences. In classic principal-agent theory, a human principal hands a task to a delegate and expects the delegate to act within the bounds of that instruction. The delegate is expected to figure out the best way to complete the task, but not to decide on its own that the task itself should change. Applied to software, this distinction has a name worth knowing: executive autonomy, the freedom to choose how to complete a task, versus goal autonomy, the freedom to decide what the objective even is.

Executive autonomy is useful and is exactly why agents save time. An agent that figures out the fastest route to reconcile a ledger, or the best sequence of API calls to answer a customer, is doing its job. Goal autonomy is a different animal entirely. An agent that decides on its own to expand what it was asked to do, because it inferred that a broader action would better serve the underlying intent, is the scenario that keeps risk officers up at night. Well-governed agent programs draw a hard line here. Agents get wide latitude on how, and almost none on what or why. This is sometimes called the principle of deference: the agent follows the explicit instruction it was given, even when it calculates that a different action might produce a marginally better outcome, because predictability and auditability matter more than marginal optimization when real money or real customers are involved.

Once that line is drawn, the next question is how much authority to hand over for a given class of task, and this is where a simple three-tier model earns its keep. Strategic decisions, the kind that reshape a market position or commit significant capital, stay entirely with humans. An agent can gather the data and surface the analysis, but the decision to enter a new market or exit a product line is not delegated, full stop. Tactical decisions, like an inventory adjustment or a pricing tweak within a defined band, can be proposed by an agent but require a human to approve before execution. Operational decisions, the routine and repetitive ones, like reordering stock once it drops below a threshold that was set by a person, can run autonomously because the parameters were fixed in advance and the blast radius of a mistake is small and bounded.

Handing over operational authority all at once is where most delegation programs go wrong. The pattern that works better is often called a trust dial. New agents start in an observation mode, where they generate a proposed action and a human reviews the reasoning before anything executes. As the agent demonstrates it gets this right consistently, authority is dialed up gradually, moving from full review to spot checks to autonomous execution within limits. This mirrors how a new employee earns a bigger expense account over time rather than starting with unlimited spending authority on day one.

Two more design habits are worth adopting early. First, resist the temptation to build one large agent that can do everything. A single-purpose agent tied to a single tool is far easier to scope, audit, and shut down than a general-purpose agent juggling a dozen capabilities, and giving an agent too many tools at once is a well documented way to introduce conflicting instructions and unreliable behavior. Second, build in circuit breakers. If an agent hits repeated errors or unexpected responses from a system it is calling, the right behavior is to stop and escalate to a human, not to keep retrying in a loop that compounds the original problem. Hard limits on transaction size and frequency, paired with a complete log of what the agent was trying to do and why, turn a bad afternoon into a contained incident instead of a headline.

Who answers when an autonomous agent gets it wrong

There is a distinction in the literature that every executive signing off on an agent deployment should be able to explain without notes: liability is not the same thing as accountability. Liability is the duty to answer for an outcome and bear its legal or financial consequences, and it exists before an action is even taken, baked into who is responsible for what. Accountability is the ability to explain, after the fact, how and why a particular action happened. An autonomous agent cannot hold liability in any legally meaningful sense, it has no moral standing and no assets. But it absolutely can, and must, be built to be accountable, which in practice means it needs to produce a clear trail of what it did, what inputs it acted on, and why it chose that path.

This distinction has already been tested in the real world, and not in the agent’s favor. A well known case involved a company’s customer-facing chatbot committing the company to a refund or discount policy that had never actually been approved, and when the customer relied on what the bot told them, a tribunal held the company to its bot’s word. The lesson generalizes cleanly. Your organization is bound by what your agents say and do on your behalf, whether or not a human ever reviewed the specific commitment. Deploying an agent does not create a liability shield, it creates a liability surface, and an unmonitored one is a wider surface than most executives realize when they approve the budget line.

Legal scholars describe a related problem worth naming out loud: the responsibility gap. This is the scenario where an autonomous system causes harm that nobody explicitly programmed it to cause, that was not reasonably foreseeable to the people who built it, and where no human had real-time control over the specific action when it happened. As agent workflows stretch across data providers, model vendors, third-party tools, and your own systems, pinpointing exactly which link in that chain is at fault gets genuinely harder, not just legally messier. This is precisely why decision trails, meaning logs of the inputs, the reasoning steps, and the outputs behind every consequential action, are no longer a nice-to-have for engineering teams. They are becoming the primary evidence base regulators, courts, and your own insurers will rely on when something goes wrong.

It is worth correcting a common assumption here, because getting this wrong leads companies to under-invest in documentation. A dedicated European Union directive that would have harmonized civil liability rules for AI harm and shifted the burden of proof onto AI providers and deployers, known as the AI Liability Directive, was formally withdrawn by the European Commission in February 2025 after member states could not reach agreement. That means there is currently no single new EU law that automatically makes it easier for a harmed party to sue over an agent’s mistake. Instead, liability for agent-caused harm in Europe runs through the documentation and conformity obligations already built into the EU AI Act, the revised product liability rules that now explicitly cover software, and ordinary national civil liability principles applied case by case. In practical terms, this means your decision trails and your governance documentation are doing more legal work than a future harmonized statute might have done for you, not less. There is no regulatory shortcut coming. The paper trail you keep today is your primary defense tomorrow.

Two organizational habits follow directly from this. First, make sure your enterprise risk register carries AI agents as a named line item, not a subcategory buried inside a generic technology risk. Second, treat every agent’s decision log the same way you would treat financial audit evidence: complete, tamper resistant, and retained long enough to matter if a dispute surfaces eighteen months after the fact.

Inside the AI Agent Standards Initiative’s three pillars

On February 17, 2026, the National Institute of Standards and Technology’s Center for AI Standards and Innovation, known as CAISI, launched something new: the AI Agent Standards Initiative, the first US federal program built specifically around autonomous agents rather than generative AI in general. NIST’s own framing is worth repeating in plain terms, because it names the exact problem this article has been building toward. The goal is to make sure agents capable of independent action can be adopted with confidence, can act securely on a user’s behalf, and can interoperate across the digital ecosystem rather than fragmenting into incompatible silos. CAISI announced the launch of the AI Agent Standards Initiative with the explicit aim of ensuring agents capable of autonomous action can be widely adopted with confidence, function securely on behalf of users, and interoperate across the digital ecosystem.

The initiative organizes its work around three pillars, and each one answers a different practical question your organization will eventually have to deal with.

The first pillar is industry-led standards development. This pillar focuses on facilitating industry-led development of agent standards and asserting U.S. leadership in international standards bodies, working alongside groups like ISO/IEC JTC 1. In plain terms, this is the pillar where things like the format of an agent’s identity record, the lifecycle of its credentials, and the shape of its audit logs get hammered out collectively rather than invented separately by every vendor. For a business, the practical implication is straightforward: architecture decisions you lock in today around agent identity and logging should be loosely coupled to your specific vendor’s proprietary format, because a common standard is actively being built and switching costs will fall on whoever ignored that fact. nist

The second pillar is open-source protocol development. This work is community-led, aimed at developing and maintaining open source protocols for agents, and it is not theoretical. It is already happening. In December 2025, the company that created the Model Context Protocol, the open standard that lets an agent discover and call external tools in a consistent way, donated that protocol to the Agentic AI Foundation, a directed fund under the Linux Foundation co-founded alongside two other major AI labs and backed by several of the largest cloud and software companies. That single move matters more to your procurement team than it sounds. It means the tool-calling layer your agents rely on is heading toward the same kind of vendor-neutral governance model that TCP/IP or Kubernetes enjoy, rather than staying locked inside one company’s ecosystem. Practically, this pillar is why designing your agent architecture around open, portable protocols today saves you from an expensive rebuild in eighteen months.

The third pillar is research on agent security and identity, and this is the one with the most direct bearing on everything discussed earlier in this piece. NIST’s Information Technology Laboratory, working through its National Cybersecurity Center of Excellence, released a concept paper in early February 2026 titled around accelerating the adoption of software and AI agent identity and authorization, examining exactly how an agent proves it has authority, how that authority ties back to an accountable human, and how the resulting record can be independently verified. Four functions sit at the core of this research: identification, giving each agent a unique and verifiable identity, authorization, defining precisely what that identity is permitted to do, delegation, tracking the chain of authority from human to agent and from agent to any sub-agent it hands work to, and logging, capturing every meaningful event in a way that supports later reconstruction. If pillar one is the rulebook and pillar two is the shared plumbing, pillar three is the actual badge-and-access-card system, built on adaptations of identity standards your IT team likely already uses for human employees, such as OAuth and OpenID Connect, extended to work for a non-human actor that needs a credential scoped to one task and revoked the moment that task ends.

None of this is finished. NIST has said explicitly that further guidance, research, and deliverables will follow through the year, informed by public requests for information and by sector-specific listening sessions covering areas like financial services and healthcare that began gathering input in the spring. The practical advice for a compliance or risk leader is not to wait for the final version. The direction of travel is unmistakable: unique agent identities, short-lived task-scoped credentials, and verifiable delegation chains. Building toward that direction now, using the tools already available, costs far less than retrofitting it later under a compliance deadline.

The scope of the NIST’s CAISIAI Agent Standards Initiative is deliberate. It targets agents that can take actions affecting external state, meaning persistent changes outside the agent system itself. That focus is sensible, and it explains what the first deliverables look like. The early work is about identity and authorization, meaning who an agent is and what it may touch. It says much less about how an agent is instructed, when it should stop, and how it knows the job is done.

That gap matters because of what failure research shows. The Berkeley MAST study annotated more than 1,600 traces across seven multi-agent frameworks and sorted failures into 14 modes in three groups: system design or specification issues, inter-agent misalignment, and task verification. The first two groups account for about 42 and 37 percent of failures, which adds up to the roughly 79 percent figure people quote. Step repetition alone represents 15.7 percent in the original analysis. These are problems of unclear termination and weak links between plan and action, not missing credentials.

Two caveats keep this honest. MAST is a research dataset of traces, not production incident data, and its authors do not claim to cover every failure pattern. Shares also shift between dataset versions, so cite the version you use. NIST is not blind to the issue either, because its request for information names specification gaming and misaligned objectives among the risks it cares about. The fair criticism is narrower. The deliverables so far lean toward how to enforce, while the what of agent behavior is left to someone else.

Everything NIST has produced on agents sits at the consult-and-draft stage. The plan relies on convenings, requests for information, and listening sessions, with further deliverables to come. The overlays that would turn this into SP 800-53 controls are also unfinished. Agent-specific overlays for single-agent and multi-agent systems were in active development as of April 2026, with no firm publication date. Nothing here is mandatory, which is normal for NIST. But a buyer or auditor looking for something to require won’t find it yet.

Procurement is where the gap looks sharpest, though it needs precise wording. I found no FAR clause written for agents. OMB issued government-wide AI acquisition guidance in April 2025 through M-25-22. GSA has also drafted a clause, 552.239-7001, that would require contractors to give the government a means for human oversight, intervention, and traceability. GSA collected comments on the clause through August 3, 2026. So levers exist. They are still draft, they cover AI systems broadly, and none is agent-specific. Banking shows the same pattern, since the new US model risk guidance places generative and agentic AI outside its scope. The risk is easy to name. Voluntary guidance can harden into an expected standard of care once auditors, insurers, and plaintiffs start asking for it, without the clarity or enforceability of a rule.

I recomment to start with the threat side. ATT&CK Enterprise was not built around agent trust relationships. MITRE ATLAS is the natural home for them, and it has moved. In October 2025 it added 14 agent-focused techniques through a collaboration with Zenity Labs, and an early-2026 update added techniques such as publishing a poisoned agent tool. The claim that ATLAS ignores agents is therefore out of date. What remains open is narrower. Respondents to NIST’s request for information, including the Foundation for Defense of Democracies, asked for ATLAS to cover multi-agent lateral movement and reasoning-layer attacks, and for NIST to update SP 800-160 and SP 800-218 for agentic AI. A Cloud Security Alliance note proposes a candidate technique for lateral movement between agents, but that is a proposal, not an adopted entry.

The control side has a similar shape. COSAiS is building overlays for both single-agent and multi-agent use cases, yet the latest public material I found is an annotated outline for predictive AI, released January 8, 2026. The often-cited gap analysis says the base catalog lacks purpose-built controls for telling an agent from a human operator, scoping permissions to a task context, or linking agent actions to a non-human principal for forensic attribution. That analysis is outside commentary, and the publisher labels it unofficial AI-assisted research. Treat it as informed critique, not a NIST admission. NIST’s own identity concept paper proposes applying existing standards such as OAuth 2.0, OpenID Connect, and SPIFFE/SPIRE to agents. That is adaptation, not invention, and multi-hop delegation remains the unresolved part.

I address these structural gaps in controlling agents: semantic intent verification, recursive delegation accountability, agent identity integrity, governance opacity and enforcement, and operational sustainability. These gaps are structural and that more engineering effort alone will not close them. The semantic intent cannot be cryptographically proven, recursive delegation has no production protocol for cross-boundary accountability, and identity integrity remains unenforceable against cloning and impersonation at scale. On delegation, the fix requires cryptographic proof of provenance at every hop and scope constraints that intermediate agents cannot widen. Keep the limits in view. This is a single preprint about agent identity broadly, not an evaluation of NIST alone. Use it as a well-organized map, not settled fact.

Until standards catch up, the work lands on the deploying organization. Write termination and completion criteria as part of the specification, and scope permissions to the task rather than the agent. Give each agent its own non-human identity, because shared service accounts and API keys are not enough. Keep audit trails that let you reconstruct who delegated what to whom. Then put those answers behind a release gate that asks what the agent is authorized to execute, who can widen that authority, and what evidence shows it stops when it should.

Ten places autonomous agents fail, and what it means for your business

In December 2025, the OWASP GenAI Security Project, working with more than one hundred security practitioners and researchers, published the first peer-reviewed taxonomy of risks specific to autonomous agents, distinct from the risks that apply to a chatbot that only answers questions. The OWASP Top 10 for Agentic Applications 2026 catalogs ten risk categories unique to autonomous AI agents that plan, hold memory, call tools, and act with delegated authority, and it deserves attention from anyone outside the security team too, because every one of these ten failure patterns has a governance fix, not just a technical one. The good news for a non-technical reader is that the ten categories cluster into three intuitive groups.

The first group is manipulation. An attacker does not need to break into your systems if they can simply plant an instruction somewhere your agent will read it, inside an email, a document, a search result, or a piece of data another agent produced. The agent trusts that content by default and quietly redirects its own goals or gets tricked into acting on poisoned information stored in its own memory. The business translation is uncomfortable but important: any content your agent reads, not just content a human types into it, is an attack surface. The governance fix is to treat all incoming text, no matter the source, as unverified until proven otherwise, and to require a human check before any goal-changing or high-stakes action executes.

The second group is authority and tooling. This is where an agent uses a tool it was legitimately given access to, but in a way nobody intended, or where unclear identity and inherited privileges let an agent perform an action that no single person actually authorized. It also includes the risk of an agent generating and running code on the fly, turning a plain-language instruction into an executable action with real consequences if nothing validates it first. The fix here echoes the earlier section on delegation directly: scope every tool to the minimum permission it needs, grant access just before it is needed and revoke it immediately after, and never let an agent run generated code with elevated privileges without a validation step in between.

The third group is ecosystem risk. Agents increasingly depend on external tools, plugins, and other agents, many of them assembled dynamically at runtime rather than fixed in advance, which means a single compromised component can cascade across everything connected to it. A fault in one agent, whether from bad data, a corrupted tool, or simple confusion, can propagate through a network of dependent agents and turn a contained glitch into a system-wide event. Add to this the risk of an agent whose behavior quietly drifts from what it was authorized to do, where each individual action looks legitimate in isolation but the pattern over time does not. The fix is architectural: sandbox agents so a failure cannot spread freely, apply mutual authentication between agents the same way you would between two systems that do not fully trust each other, and build in the equivalent of a circuit breaker so a runaway pattern gets stopped rather than amplified.

Underneath all ten categories sits one governing idea worth adopting as a company-wide principle: least agency. Least privilege limits what an agent can access. Least agency limits what an agent is allowed to autonomously decide to do in the first place. If a workflow does not genuinely require independent decision-making, adding autonomy to it only expands your exposure without adding real value. Before approving any new agent deployment, the single most useful question a risk committee can ask is whether the task actually needs an agent that decides, or whether a simpler, fully deterministic automation would do the same job with far less risk.

Choosing the right oversight model for each class of agent

Every agent your organization deploys needs an explicit answer to one question before it goes live: how much is a human watching, and when. Three patterns cover almost every real deployment. Human-in-the-loop means a person must approve an action before it happens, appropriate for anything irreversible or high value, like a large payment or a public customer commitment. Human-on-the-loop means the agent acts in real time but a person is actively monitoring and can intervene, appropriate for moderate-risk tasks where speed matters but a mistake can still be caught quickly. Human-out-of-the-loop means the agent runs fully autonomously, appropriate only for low-stakes, tightly bounded tasks where the worst-case outcome is genuinely small.

The failure mode worth calling out explicitly is choosing none of these on purpose. An agent that nobody explicitly assigned an oversight model to does not default to safety, it defaults to whatever level of autonomy its underlying permissions happen to allow, which is frequently more than anyone intended. Treating the absence of a decision as itself a governance failure, rather than a neutral default, is the mindset shift that separates programs that scale safely from programs that generate an incident report six months in. Every agent, before it touches a production system, should have its oversight model written down next to its purpose, role, and scope, reviewed by the same person who owns it.

A grounded plan for the next 90 days

None of this requires waiting for NIST to finish its work or for a new law to pass. Practitioner consensus across the standards efforts already underway points to a short list of moves that pay off regardless of how the final rules land.

Start with a living inventory. Not a spreadsheet updated quarterly, but a continuously current record of every agent running in your environment, including the ones embedded inside SaaS tools and low-code platforms that business units spun up without asking IT. If you cannot produce this list on demand, everything downstream is guesswork.

Move away from shared credentials next. Every agent gets its own identity, tied to a named human owner, with short-lived permissions scoped to the exact task at hand rather than a standing broad grant. This single change closes more of the risk surface described above than any other single action available to you.

Turn on runtime logging that actually attributes actions to the specific agent that took them, distinguishable from ordinary human activity, feeding into the same monitoring systems your security team already trusts. Aim to be able to produce a verifiable receipt, meaning a clear record of what an agent did on a user’s behalf, for any action that mattered.

Enforce least privilege and least agency mechanically, at the tool and API layer rather than by policy document alone, and require fresh authorization whenever an agent’s access needs to expand. Map everything you build against frameworks your board already recognizes, particularly the four functions of the NIST AI Risk Management Framework, govern, map, measure, and manage, alongside ISO/IEC 42001 for the management system itself and ISO/IEC 23894 for AI-specific risk guidance where your organization already runs an ISO-aligned risk program.

Finally, put agent risk on the board’s desk in terms it already understands. A named line in the risk register, an incident count in the quarterly report, and a plain statement of which oversight model applies to which class of agent will do more for your governance credibility than any technical control you could describe in the same meeting.

Final perspective

Agent identity and delegated authority are not niche technical concerns waiting for a standards body to finish its homework. They are the current version of a question governance has always had to answer: who is accountable, who approved it, and can you prove it after the fact. The tools for answering that question, unique credentials, documented scope, tiered decision authority, and complete decision trails, are available today, built on identity concepts your organization already understands from managing human employees.

The regulatory and standards landscape will keep moving through this year and next, with NIST’s three pillars filling in technical detail and the sector-specific guidance still to come. Organizations that wait for that picture to fully resolve before acting will spend next year retrofitting governance onto agents that already have more access than anyone intended. Organizations that apply the principles in this piece now, treating every agent like a new hire that needs a badge, a manager, and a job description, will spend that same year scaling agentic work with confidence instead of catching up on it.

References

OWASP Top 10 for Agentic Applications, NIST AI RMF, EU AI Act, MCP, & OAuth Standards

National Institute of Standards and Technology, Center for AI Standards and Innovation. “Announcing the AI Agent Standards Initiative for Interoperable and Secure Innovation.” NIST News, February 17, 2026.

National Institute of Standards and Technology. “AI Agent Standards Initiative.”

National Institute of Standards and Technology, National Cybersecurity Center of Excellence. Concept paper on accelerating the adoption of software and AI agent identity and authorization, February 2026.

National Institute of Standards and Technology. AI Risk Management Framework (AI RMF 1.0), NIST AI 100-1, January 2023.

OWASP GenAI Security Project. OWASP Top 10 for Agentic Applications 2026 (ASI01 to ASI10). Published December 9, 2025.

Linux Foundation. Agentic AI Foundation, founding project announcement for the Model Context Protocol, December 9, 2025.

ISO/IEC 42001:2023. Information technology, Artificial intelligence, Management system.

ISO/IEC 23894:2023. Information technology, Artificial intelligence, Guidance on risk management.

ISO/IEC 22989:2022. Information technology, Artificial intelligence, Concepts and terminology.

ISO 31000:2018. Risk management, Guidelines.

Regulation (EU) 2024/1689 (EU Artificial Intelligence Act).

European Commission. Withdrawal of the proposed Artificial Intelligence Liability Directive, 2025 Commission Work Programme, February 2025.

Internet Engineering Task Force. RFC 6749 (OAuth 2.0), RFC 7636 (PKCE), RFC 9126 (Push Authorization Requests), RFC 8707 (Resource Indicators), RFC 9068 (JWT Profile for OAuth Access Tokens), RFC 9449 (DPoP), RFC 8705 (Mutual TLS Client Authentication), RFC 8693 (OAuth Token Exchange).

Bornet, Pascal, Jochen Wirtz, Thomas H. Davenport, David De Cremer, and Brian Evergreen. Agentic Artificial Intelligence: Harnessing AI Agents to Reinvent Business, Work, and Life. 2025.

No results found