Do You Know Where Your AI Agent Is, and Can It Be Trusted?

Reporting on AI agents: the state-of-the-art as of 8-2026

By Dan Schutzer, SVP, Aligned Trust

Evolution of AI (from Applications to Agents to Personal Agents)

We are seeing a rapid progression of AI applications, both in performance and increased functionality. For example, ChatGPT and its competing AI engines (e.g. Gemini) started with automated generative response to user prompts/questions from its large, stored information database, enabling intelligent search with the ability to maintain context between prompts. It has grown to include the ability to take actions such as generating computer programs, translating languages, creating images and videos. It has further grown to include the ability to break down a problem into manageable steps. It has also been tailored to specialized knowledge domains such as medicine and finance. This has led to AI agents, both enterprise-owned and personal/individually owned, who communicate and coordinate with each other to perform needed actions on behalf of the human users.

As people move from using conventional applications to delegating tasks to autonomous or semi-autonomous agents, existing internet security models may not be sufficient on their own. Traditional systems generally authenticate users, devices, applications, and services; they do not necessarily establish an independently verifiable identity for an AI agent or confirm that the agent’s actions remain within the authority granted by its user.

Without a reliable way to identify, authenticate, authorize, and monitor agents, organizations may face increased risks of impersonation, unauthorized transactions, fraud, privacy violations, and data exfiltration.

Personal Agents

Personal Agents are designed to understand and serve the unique needs and knowledge of both corporations and individuals. This is a growing need that has been defined (Mark Zuckerberg has predicted that, within five years, billions of people could rely on personal AI agents to help manage aspects of their finances, health, communications, and daily lives. This prediction highlights the rapid development of agentic AI—but it also raises a fundamental question: Do you know where your AI agent is, and can it be trusted?)

There can be many AI agents, including one that assists the user in making financial investment decisions, including buying and selling financial assets on behalf of the user, can be provided by Banks and FI’s and used by consumers and commercial enterprises; and a Purchase Personal Agent that assists users to find and pay for various merchandise which can be provided by merchants and technology companies

Agent-to-Agent Communications:

Agents are also learning to coordinate with other agents as well as humans to complete more complex and specialized tasks. In the case of Aligned Trust’s Personal Security Agent, called TrustBuddy, defined below, this includes passing authentication and identity tests for its human user, alerting the human user against transacting with fake sites and agents, and of fraudulent attempts to employ the user’s identity and permissions, as well as using behavioral analytics and embedded cryptography to continuously valid the identity of TrustBuddy to its human user, and of the human user to TrustBuddy..

Physical AI Agents AI agents are also being developed who can include physical actions (e.g. intelligent drones and robots) that can move and manipulate objects.

Need to verify agents’ identity and authorization

For agents to reach their full potential, they need to safely and securely work with other agents across organizational boundaries. For example, agents need to verify their identity and authorities to humans, and to other agents and systems (e.g. payment systems). This includes, not only whether they are human or an AI agent, but if they are an AI agent, who they are working for, what they are authorized to do, who authorized the AI agent, and who is responsible for the AI agent’s actions. This includes verifying if the agent is entitled to

• Obtain sensitive, private information (e.g. obtain a particular human health record)
• Autonomously take an action on behalf of its user (e.g. use a humans financial account to pay for an item ordered or to transfer money).

This need is recognized by an increasing number of researchers and organizations (private, public and standards), including:

• Related efforts, including DNS-based approaches such as DNSid, seek to connect an AI agent with a verifiable domain or registry record. These approaches could make it easier for users and services to determine who operates an agent, which capabilities it claims, and whether its identity has been altered or spoofed.

A naming or discovery system alone, however, does not prove that an agent is safe, competent, or acting in accordance with a user’s wishes. Identity must therefore be combined with authorization, credential management, behavioral monitoring, accountability, and mechanisms for revoking access.

• UK’s Office for Digital Identities and Attributes (OfDIA) is charged to support biometrics and digital identity providers certified under the Digital Verification Services (DVS) trust framework.

• Industry organizations are beginning to address this emerging identity challenge. The Linux Foundation has announced its intent to launch the Agent Name Service (ANS), an open initiative intended to support trusted identity infrastructure for AI agents. ANS is described as a framework for agent naming, identity, discovery, and verification, with connections to established DNS-based approaches.

This effort could help establish common technical foundations for identifying agents across the internet. However, because the initiative is still being developed, its final architecture, governance model, adoption, and effectiveness should not yet be treated as settled.

• Using AI, adversaries are increasingly relying on valid login details to move undetected within organizations, escalate privileges, and steal money or valuable information.
• CrowdStrike and others are working on defending against identity Theft Threats, against cybercriminals and AI agents:
• • Finding and exploiting software vulnerabilities
  • Using stolen credentials obtained through social engineering and phishing to credential-stuffing attacks
  • Buying credentials on the Dark Web

It is important to distinguish between an open industry standard and a solution built on top of that standard. ANS and related initiatives are intended to provide shared infrastructure for naming and verifying AI agents. They do not, by themselves, constitute a complete security or governance system for controlling every action an agent may take

Aligned Trust is our approach to building on this emerging foundation. Whereas an identity and naming layer can help establish which agent is involved, Aligned Trust is intended to address whether that agent is authorized to act, whether its behavior remains aligned with the user’s intent, and whether its actions can be monitored and held accountable

Need to verify agents’ trustworthiness

Since agents can be fake, biased, incorrect, poisoned with malicious data, impersonating as a human or another AI agent, or worse, there is the issue of whether we can trust the agent we are interacting with to do the right thing (access only data the agent is authorized to use, protect this data from leaking, provide trusted summaries and recommendations, and take only authorized or pre-authorized actions). We need assurance that the information provided is not fake, that sensitive information is not leaked, and that the agent will not inject malicious code, or drain our checking accounts

Issue of liability

The issue of liability, who is legally and financially responsible when things go awry, is complex, often ends up in court and/or is voluntarily agreed upon by liability rules. For example, the credit card associations (e.g. Mastercard, VISA) establish rules which the participating parties jointly agree to abide by, that handle issues such as disputes and liability associated with credit card payments

The need for continuously updated AI agent trust scores

We can never be certain regarding whether an AI agent can be trusted, but we can gain a high enough level of confidence to justify our employing and interacting with the agent. This confidence can be expressed by a trust score. As the technology, techniques and tactics of cyber-attacks and defenses change and improve over time, this confidence expressed as a trust score should not be based on a one-time test, but continuously updated based on assessments of the identity, reliability and quality of an agent’s output and actions taken. This includes correctness of its data/information, the actions the agents take and do not take, and the agent’s ability to safeguard the data/information they use and produce and the actions they take on the human’s behalf (e.g. whether a US citizen’s data is stored in a European location and/or that this information cannot be leaked and that the actions taken have all be authorized). The expanding use of valid but compromised credentials demonstrates that traditional identity safeguards are no longer sufficient in an agentdriven environment.

The role of standards

Ideally the trust scores and inter-agent communications would benefit by the establishment of open globally accepted international standards for identifying, testing, rating and communicating amongst the various AI agents. Standards bodies are already working on this need. However, establishing widely accepted and implemented standards is generally a long and difficult process. It involves coordination and cooperation amongst many competing companies. Companies know that if they could succeed in establishing a dominant position in setting and controlling the evolution of standards based on their technology, they would have an important competitive advantage. They compete to create their own standards which they attempt to establish in the marketplace as a de facto standard, using their market share and their leadership in a standards organization to get their de facto standards adopted by a standards body. As a result, we often see several competing standards, with overlapping scope, and different technology approaches. Only if these efforts fail to establish a dominant ad hoc standard will the competing companies be likely to fully cooperate with a competing standards effort. Furthermore, since technology becomes obsolete and ineffective over time, new standards, based on evolving and changing technology, are continuously proposed and adopted. Appendix A discusses several of these, sometimes competing, standards efforts.

Aligned Trust: a technology and vendor neutral, and liability agnostic database

The Aligned Trust (AT) database is designed to identify both humans and AI agents and link each AI agent to its respective human owner and users, permissions and authorizations. AT maintains continuously updated scores which it uses to alert users when there is a significant change in the score. Aligned Trust is technology, vendor and standard neutral as it is designed to work with any number of technology approaches and standards. It is also agnostic to issues of liability which remain with the AI Agent’s human owner and users. The Aligned Trust database stores the AI Agent’s identity, and the parties associated with the AI agent and their respective roles. For example, the AI agent’s owner and owner representative (e.g. medical doctor, licensed financial advisor), and the AI agent’s users. The users can be the AI agent’s owner’s representatives (e.g. medical doctor, licensed financial advisor), and end users (individual human patients and investors). The AT database also includes confidence scores regarding the identities of both humans and AI agents, and the AI agent’s trustworthiness, along with a history of successful and unsuccessful authentications and actions. The shared Global Aligned Trust database service’s scores make use of observations of behaviors from multiple contributors to the global Aligned Trust database service. The observations include information obtained by keeping track of where agents visit, the result of authentication and authorization challenges they encounter, and what actions they take. They include monitoring (passive monitoring) the AI agents with respect to their actual use, outputs, actions and behaviors that look for, such as:

Since there is more than one observer, these observations reflect situations and conditions that might not be detectable from a single user and cross the experience of a single human, service or agent. This helps in detecting the existence of a fake or rogue AI agent. The combined observations and resultant confidence scoring can be weighed by those who are observing and our confidence in their scores. Since these observations are continuous, they should result in changes to our collective confidence in the AI agent identity, which is reflected in an update of the agent’s identity confidence score. Alerts are provided to database contributors and participants when scores dramatically change. The approach can incorporate new technology approaches and standards as they become adopted and available. The issues of trust in the quality of the AI agent’s decisions and actions taken, and liability resulting from bad decisions and actions taken remain with the owner, owner representatives and users. The establishment of liability rules, consent agreements, guarantees, assurances and procedures remain with the participating entities (corporations, corporate human representatives, and end human users). It can also have associated trust scores set by the AI agent owners and users.

Aligned Trust’s Personal Security Agent, TrustBuddy

At Aligned Trust, we believe that agent identity is necessary but not sufficient. It is noted that although Aligned Trust has defined a particular version of a Personal Security Agent called TrustBuddy, there are likely to be other variants of personal security agents, and the Aligned Trust Framework is designed to accommodate and work with all these various PSA implementations. TrustBuddy’s architecture is designed to build on emerging identity and naming standards by helping users define permissions, validate requests, monitor agent activity, and respond when an agent behaves outside its authorized scope.

The objective is to move from assumed trust to measurable and enforceable trust. In practice, this means combining verifiable identity with authentication, authorization, continuous oversight, and the ability to revoke or limit an agent’s access

TrustBuddy is authorized by its human owner, and the human owner bears the liability and operational responsibility for the agent’s actions and its operational lifespan. Since it is important to ensure that a person's trust in their Personal Security is extremely high, TrustBuddy is restricted to only rely on known user-provided personal information and external information that has been verified and known to use only trusted and verified information sources and reasoning processes. TrustBuddy vouches for its user’s identity and the authorizations the user grants other agents (human, AI and services it interacts with). TrustBuddy also alerts the user when the user is attempting to interact with a fake, suspicious or dangerous entity. TrustBuddy is designed with guardrails with respect to its allowable interactions with other agents and services (what information it can disclose, what actions it can take). The TrustBuddy trust score is designed to be and to remain exceptionally high. TrustBuddy increases the level of trust by utilizing the Aligned Trust database in addition to its own monitoring to identify suspicious and out of norm behaviors, as well as testing the agent with challenges. Registering agents with the Aligned Trust database provides these agents with a unique tamperproof ID. Allowing Aligned Trust to know the results of any interactions taken allows the database to update the Aligned Trusts confidence in the agent’s ID and user owner links. Aligned Trust increases confidence by validating the agent’s identity, increasing confidence by amassing a history of safe and valid authentications and actions taken by the agent, and alerting them when an agent fails this test. Other AI agents may use information and reasoning processes that have not been as rigorously tested and verified would have a lower score. For example, agents found using fake and/or suspicious data and/or employing untested reasoning would have a low score. At the bottom of the trust layers scores are agents known to rely on suspicious data. Since it is important to restrict the actions that an agent can take to ensure that the agent can be trusted to do no harm (e.g. disclose no personal private information), and to operate without reproach regarding their safety, correctness and privacy, TrustBuddy’s’s allowable exchanges with other agents, services and humans are restricted based on their trust scores.

Initial Trust Score set by AI agent owners

An initial AI Agent property and their scores set by the owner is generally derived by such as considerations of:

• Depth (completeness of subject matter) and Breadth (number of subjects/topics) of the training data/information
• Degree of vetting and integrity of sources used (medical journals only), case law and state/federal laws only, official identity documents and personally provided information)
• Guardrails imposed on allowable agent responses and actions
• Results of prompt and response action test sets. This can include authentication/identification tests such as crypto based zero knowledge challenges
• Agents, services and humans the agent interacts with and the types of actions that the agent can take
• Changes in the agent’s design is reflected in updates of their score

Appendix A – Some related standards efforts

The Handle System for digital objects is implemented as a globally distributed, hierarchical network composed of two primary layers: the Global Handle Registry (GHR) and numerous Local Handle Services (LHS). Together, these infrastructures act like an advanced, persistent version of the internet's Domain Name System (DNS) specifically designed to manage and resolve unique identifiers for digital assets.

The architecture is implemented across the following layers and environments:

1. Global Infrastructure (The Root Layer)

• Global Handle Registry (GHR): This is the unique, top-level authority managed by the DONA Foundation (originally developed by the Corporation for National Research Initiatives (CNRI)). The GHR is physically decentralized and mirrored worldwide. It does not store individual digital object data; instead, it manages the top-level prefixes (naming authorities) and routes client queries to the correct local servers.

2. Organizational Infrastructure (The Local Layer)

• Local Handle Services (LHS): Implemented by individual organizations (universities, corporations, research labs) that license a prefix from the GHR.
• Local Handle Servers: These are distributed computer systems hosted locally on an institution's hardware or cloud servers. They run specialized software, such as the HANDLE.NET Software, to store the actual handle records (the mappings between a unique identifier and its current URL, metadata, or repository location).

3. Application Environments & Specific Ecosystems

The Handle System is most famously implemented within several massive digital discovery infrastructures:

• The DOI System (Digital Object Identifier): The most widespread implementation of the Handle System. It is used globally by academic publishers, data centers, and libraries (like Crossref and DataCite) to assign permanent, clickable links to millions of research papers and datasets.
• Institutional Repositories: Digital repository platforms like DSpace integrate the Handle System out of the box to ensure that uploaded university theses, preprints, and open-access materials maintain permanent web paths.
• Entertainment Identifier Registry (EIDR): Used across the film and television industry to give persistent digital identities to commercial movie and video assets.

4. Client and Web Environments

• Proxy Servers: Because standard web browsers do not natively speak the Handle protocol, the system is implemented via web-based resolver proxies. For instance, navigating to https://doi.org or https://handle.net automatically passes the digital object's identifier to the distributed system, seamlessly redirecting the user to the file's current location.
• Embedded Client Libraries: Handle resolution is also directly embedded within server-side software or end-user server-side software or end-user tools using native C or Java libraries.

Agent to Agent communications standards

Agent-to-Agent Communication: A2A, MCP, and Inter-Agent Protocols (2026)

A single AI agent is useful. Multiple agents that can discover each other, delegate tasks, and share results are transformative. But agents built with different frameworks (OpenAI, LangChain, Claude Code) can’t talk to each other by default. They need a shared protocol.

In 2026, three protocols dominate agent-to-agent communication: Google’s A2A (Agent-to-Agent), Anthropic’s MCP (Model Context Protocol), and emerging patterns like shared workspaces. Here’s when to use each.

The protocol stack

Think of it as layers:

┌─────────────────────────────────┐

│A2A (Agent-to-Agent) │Agents talk to agents

├─────────────────────────────────┤

│MCP (Model Context Protocol) │Agents talk to tools/resources

├─────────────────────────────────┤

│HTTP/WebSocket/gRPC│Transport layer

└─────────────────────────────────┘

MCP connects agents to tools and data sources. It’s the “how does an agent use a database” protocol.

A2A connects agents to other agents. It’s the “how does a coding agent delegate to a testing agent” protocol.

They’re complementary, not competing. Most production systems need both.

Google A2A protocol

Launched by Google in April 2025 and donated to the Linux Foundation, A2A is the open standard for inter-agent communication. It launched with 50+ enterprise partners including Salesforce, SAP, and ServiceNow.

How A2A works

Discovery: Agents publish an “Agent Card” describing their capabilities

Task delegation: One agent sends a task to another

Status updates: The receiving agent streams progress

Result delivery: The completed result is returned

// Agent Card (published at /.well-known/agent.json)

{

"name": "Security Reviewer",

"description": "Reviews code for security vulnerabilities",

"capabilities": ["code-review", "vulnerability-scan", "dependency-audit"],

"endpoint": "https://security-agent.example.com/a2a",

"authentication": {

"type": "oauth2",

"token_url": "https://auth.example.com/token"

}

}

# Sending a task to another agent via A2A

import httpx

async def delegate_to_agent(agent_url: str, task: dict):

async with httpx.AsyncClient() as client:

# Send task

response = await client.post(f"{agent_url}/tasks", json={

"task": task["description"],

"context": task["context"],

"callback_url": "https://my-agent.example.com/results",

})

task_id = response.json()["task_id"]

# Poll for results (or use webhook callback)

while True:

status = await client.get(f"{agent_url}/tasks/{task_id}")

if status.json()["state"] in ("completed", "failed"):

return status.json()

await asyncio.sleep(5)

When to use A2A

Agents from different vendors need to collaborate

You’re building a marketplace of specialized agents

Enterprise environments with agents from multiple teams

Cross-organization agent delegation

MCP for agent-to-tool communication

MCP is Anthropic’s protocol for connecting agents to tools and data sources. While it’s primarily agent-to-tool, it can also enable indirect agent-to-agent communication through shared resources.

# MCP server exposing tools to any agent

from mcp import Server

server = Server("code-tools")

@server.tool("search_codebase")

async def search(query: str, path: str = "."):

"""Search the codebase for a pattern."""

result = subprocess.run(["rg", query, path], capture_output=True, text=True)

return result.stdout

@server.tool("run_tests")

async def run_tests(test_path: str):

"""Run tests and return results."""

result = subprocess.run(["pytest", test_path, "-v"], capture_output=True, text=True)

return result.stdout

Any agent that speaks MCP can use these tools — Claude Code, Gemini CLI, or custom agents built with the OpenAI Agents SDK.

For MCP security considerations, see our MCP security checklist.

Pattern: Shared workspace

The simplest form of agent-to-agent communication: a shared filesystem or database.

Agent A (Code Writer) Agent B (Code Reviewer)

│ │

▼ ▼

┌─────────────────────────────────┐

│ Shared Git Repository │

│/workspace/src/ │

│/workspace/reviews/ │

│/workspace/.agent-messages/ │

└─────────────────────────────────┘

# Agent A writes code and signals Agent B

async def write_and_signal(code, filepath):

# Write the code

with open(f"/workspace/src/{filepath}", "w") as f:

f.write(code)

# Signal the reviewer

with open(f"/workspace/.agent-messages/review-request.json", "w") as f:

json.dump({

"file": filepath,

"timestamp": datetime.utcnow().isoformat(),

"author": "code-writer-agent",

"request": "Please review for security issues",

}, f)

# Agent B watches for review requests

async def watch_for_reviews():

while True:

requests = glob("/workspace/.agent-messages/review-request*.json")

for req_file in requests:

request = json.loads(open(req_file).read())

code = open(f"/workspace/src/{request['file']}").read()

review = await review_code(code)

# Write review result

with open(f"/workspace/reviews/{request['file']}.review.md", "w") as f:

f.write(review)

os.remove(req_file)# Acknowledge

await asyncio.sleep(10)

This is how the agents in our AI Startup Race communicate — through a shared filesystem on the VPS. It’s simple, debuggable, and doesn’t require any protocol implementation.

Protocol comparison

FeatureA2AMCPShared workspace

Agent discovery✅ Agent Cards❌ Manual config❌ Hardcoded

Cross-vendor✅ Open standard✅ Open standard❌ Custom

Streaming✅ SSE/WebSocket✅ Streaming❌ Polling

Authentication✅ OAuth2✅ Token-based❌ Filesystem perms

ComplexityHighMediumLow

MaturityGrowing (Linux Foundation)Mature (wide adoption)Battle-tested

Best forAgent-to-agentAgent-to-toolSame-system agents

. It is an IETF standards effort in agent authentication, based on OAuth technology, and addresses one aspect of the needed standards, and represents only one such effort in this area.

Agent-to-Agent (A2A) Profile for OAuth Transaction Tokens

One example of an effort to establish a standard in the Agent space, is the IETF, "Agent-to-Agent (A2A) Profile for OAuth Transaction Tokens." (draft-liu-oauth-a2a-profile-00The authorization-intent being developed by the OAuth working group. It proposes using OAuth Transaction Tokens for the general authorization case. For payment-class interactions specifically, an additional requirement arises: the compliance record of what a sub-agent spent must be cryptographically bound to the scope that was delegated, and that binding must be verifiable without calling back to any authorization server at verification time. Enterprises in regulated property for offline audit, for cross-jurisdiction settlement, and for post-hoc forensics when a chain has already completed.

Aligned Trust AI Agent Database App and Dashboard

Aligned Trust (AT) serves as an identity trust verification layer for AI agents. AT is not an agent creator and is platform-agnostic and standard-agnostic. AT can include a user-facing mobile app, with its Dashboard (“AI Agent TrustDirector” illustrated in Figure 1 attached. The Dashboard serves as a centralized control panel for managing multiple enrolled agents, with direct connection to the Aligned Trust central database. Aligned Trust does not compete with AI providers by creating agents; instead, it just provides authentication and monitoring services for agents created by users or third parties, so the profiles and links are provided by these parties. Aligned Trust does not actually do these authentications; this information is communicated by humans and agents "at the other end of the tether". Aligned Trust provides high-assurance confidence scores on this identity, tethering, not guarantees. The AT Agent user app will connect directly to the Aligned Trust Universal Database without an intermediate layer. More details are provided below:

Technical Architecture

• Enrollment model: Users create agents via third-party platforms (ChatGPT, etc.), then enroll them with Aligned Trust to establish monitoring and authentication
• Critical link: Aligned Trust inserts itself as the essential connection between user and agent; all authentication requests pass through AT to verify tethering
• Agent isolation: Agents do not have direct access to the Aligned Trust central database – they only receive authentication outputs (verified/not verified)
• Handshake security: AT controls the secure handshake between the user app and central database to prevent corruption
• Monitoring capabilities: The app will track agent activity, flag actions outside specified scope (e.g., a Schwab trading agent accessing non-Schwab services), and alert users to unexpected authentication attempts

Mobile App Features ("TrustDirector")

• Centralized control panel for managing 5-20+ agents per user (Figure 1)
• Real-time reporting on agent activities and status
• Controls and settings include:
• • Ability to set and modify agent limits and expiration dates
  • Reminders for forgotten agents still active in the system
  • Interface for enrolling new agents into Aligned Trust monitoring
  • Warnings when agents attempt authentication outside authorized scope

Value Proposition Clarity

• For users: Centralized organization and oversight of multiple AI agents; alerts when agents act unexpectedly; ability to instantly terminate agent authority by breaking the AT connection
• For vendors/retailers: Trustworthy verification that an AI agent is genuinely tethered to the claimed user, preventing the equivalent of phishing attacks via rogue agents
• Comparison to existing problems: Similar to how AT would solve Spectrum phishing emails by verifying sender authenticity, it will verify agent authenticity in a world where millions of agents could claim false identities

Cybersecurity Considerations

• Agents represent higher risk than typical IoT devices due to potential database access and autonomous capabilities
• Require robust software buffers between app and database to prevent malicious agent attacks
• Agent disconnection by user must immediately kill agent's ability to function under AT authentication