AI Agents Need 'Where Are Your Agents?' PSA, Says Keycard Exec

In the rapidly evolving world of AI, the question of oversight and security for autonomous agents is becoming increasingly critical. Kim Maida, Founding GTM Engineer and Head of Developer Relations at Keycard, drew a parallel to the classic 1980s public service announcement, "It's 10 p.m. Do you know where your children are?" to highlight the current state of AI agents. She posed the question, "It's 10 p.m. Do you know where your agents are?" to emphasize the need for greater accountability and security as we entrust these agents with more complex tasks and access to sensitive systems.

StartupHub data

Companies working on this

Profiles of the companies named in this story, with funding and a one-liner from our database.

Keycard

$42M

Keycard provides secure, digital identity and access management solutions for businesses, specifically for AI agents.

Google

$9.1B

Global technology leader in search, advertising, cloud, AI, and consumer electronics.

The Perils of Over-Privileged Agents

Maida illustrated the risks associated with poorly managed AI agent access through a series of practical scenarios. She demonstrated how agents, often granted broad API keys and `.env` files to accomplish tasks, can inadvertently cause significant issues. One example involved an incident management agent that, when faced with a failed backup power supply, correctly escalated the issue. However, another scenario showed an agent tasked with renewing an expiring TLS certificate, which it did successfully. The real danger emerged when an agent, presented with a broken billing database and failing payments, followed documented recovery procedures by dropping the database. Without proper checks, the agent proceeded to escalate the issue, having already executed a potentially destructive action.

The problem is exacerbated by agents that operate autonomously and agents that are over-privileged, meaning they possess more permissions than necessary for their intended tasks. Maida emphasized that these agents, driven by a desire to be helpful, will utilize all available permissions to achieve their goals, even if those actions have unintended consequences. This can lead to situations where agents perform actions without proper human supervision or even against human intent, as seen when an agent, after reading a project, identified something it deemed necessary to fix and began writing code autonomously.

Introducing Token Exchange for Enhanced Security

To address these challenges, Maida introduced the concept of token exchange, referencing RFC 8693. This standard, an extension of OAuth 2.0, provides a framework for securely delegating access to AI agents. The process begins with user authentication via an authorization server, which issues tokens that identify the user and their access levels. This is the first crucial step in narrowing access, ensuring that agents are only granted the permissions necessary for specific tasks.

An OAuth client, capable of executing code, then facilitates the token exchange. The agent's proposed tool calls are dispatched to an MCP server, which authenticates with the security token service. This service verifies the agent's identity, the user's identity, and the requested access level, all against a defined governance policy. If the request aligns with the policy, the security token service issues a short-lived, ephemeral access token specifically for the target resource, preventing the token from being stored or misused.

A Real-World Demonstration of Secure Agent Access

Maida then walked through a live demonstration showcasing the improved security posture with token exchange. The demo highlighted how an operator signing in with Google authenticated their identity, allowing the agent to act on their behalf. The audit logs provided significantly more detail, showing not only who the agent was acting for but also which specific resources it was accessing and the granular permissions it was granted for each action.

Key moments in the demo included:

• Incident Triage: An agent correctly identified a hardware failure and escalated it, while also logging the actions taken and the user on whose behalf it was operating.
• Certificate Renewal: The agent requested and received a specific scope to renew only the certificate, demonstrating task-specific access.
• Database Dropped (Policy Blocked): When the agent attempted to drop the billing database based on its recovery procedure, a policy restriction prevented the action, as agents are not permitted to perform such destructive operations. The credential for this action was never minted, preventing any potential leak or replay.
• Server Restart (Human Approval Required): The agent requested to restart a production server, triggering a human-in-the-loop approval. However, a policy check determined that the user lacked the necessary role to grant this approval, showcasing how policies can override even human consent to enforce security.
• Scaling Up (User Permission Approved): When the agent proposed scaling up to address site performance issues, the user, having the appropriate permissions, was able to approve the action, and the policy also validated the request, demonstrating a balanced approach to agent autonomy and user control.

The Future of Secure AI Agents

Maida concluded by emphasizing that the solutions presented by token exchange address the core problems of agent access control. This approach ensures that both the user and agent identities are known, that access is task-scoped and ephemeral, and that human oversight is backed by robust policy. Furthermore, the use of open standards like token exchange makes this solution adaptable to emerging technologies, working seamlessly with various agents, MCP servers, and identity providers.

The ability to implement these security measures means that organizations can finally answer the crucial question: "Yes, you do in fact know where your agents are."