The house sitter problem: Why AI agents still have the keys

The vacation that wasn’t over 

You hire a house sitter while you are out of town for two weeks. The requirements are simple: water the plants, bring in the mail, and take care of the dogs. You hand over the keys, walk through expectations, and leave feeling like a responsible homeowner. 

The vacation was great. You return home, everything looks fine, and life resumes as normal. Then, a week later, you come home early for lunch. 

You find your house sitter and several of their friends by your pool, eating pizza ordered through your Alexa on your Uber Eats account and helping themselves to your bourbon and wine collection. 

Two realizations set in immediately. You never took the keys back, and the person with access interpreted that access far more broadly than you ever intended.

This wasn’t a break-in. Nothing was hacked or forced. Your house sitter used the key you gave them and made a series of decisions that were each, individually, enabled by the access you provided. The failure wasn’t security. It was governance. Your security never accounted for what would happen after a task ends or how access might be interpreted once it is granted. 

This is the exact problem we’re about to face at enterprise scale with agentic AI. 

The agent in the house 

When organizations bring an AI agent online, whether it’s managing calendars, processing invoices, triaging support tickets, or orchestrating multi-step workflows, they are functionally handing over the keys. The agent receives credentials, API tokens, service account access, and delegated permissions. It’s given a set of tasks and pointed at the systems it needs to accomplish them. 

And just like the house sitter, everything works fine until it doesn’t. 

The challenge isn’t that AI agents are malicious. They’re not acting out of spite. The problem is that agentic AI introduces a category of risk that our existing security frameworks were never designed to handle. 

A traditional service account does exactly what it’s coded to do. An AI agent is different. It has a goal; it has access, and it has the ability to chain those together in ways that are technically authorized but operationally unintended. This is not a vulnerability. It’s a design characteristic and one we’re not governing for. 

There are three distinct failure modes at play here, and each one maps directly back to our house sitter. 

Failure mode 1: Authorization outliving intent 

You forgot to get the keys back 

The house sitter’s job was to watch your house for two weeks. That job ended. But the keys and the authorization persisted. Nobody revoked them. Nobody even thought about it, because in the moment you handed them over, the focus was on enabling the task, not on what happens after.

This is the temporal boundary problem, and it’s endemic in how organizations deploy AI agents today. When an agent is provisioned to handle a project, process a batch of transactions, or manage a time-bound workflow, it receives credentials that enable it to operate. But when the task is complete, those credentials don’t automatically expire. The OAuth tokens persist. The service account remains active. The API keys continue to work. 

In a traditional IT environment, this is the “orphaned account” problem that every CISO knows, and few have fully solved. But with agentic AI, the stakes are higher because the entity holding those credentials isn’t a static piece of code. It’s something that can actively use them. An orphaned service account is a latent risk. An AI agent with persisting credentials is an active one. 

The question every CISO needs to ask: 

When the task ends, does the authorization end with it? If the answer is “we need to check,” you have a house sitter with your keys. 

Failure mode 2: Scope exceeding intent 

They used your identity, not their own 

You asked the house sitter to water the plants, bring in the mail, and walk the dogs. What you actually gave them was the ability to act like you. Your key opens every door. Your Alexa responds to anyone’s voice. Your Uber Eats account doesn’t know or care who placed the order. 

This is the privilege boundary problem. The house sitter wasn’t given a scoped role with clearly defined limits. They were given your master key and your identity, and the constraints on its use were entirely implicit. You expected them to limit themselves. 

In the AI context, this happens every time an agent is provisioned with a broad service account, an admin-level API key, or delegated permissions that match the provisioning user’s access rather than the agent’s actual task requirements. We give the agent the ability to do everything we can do and then hope it only does what we meant. 

Least privilege isn’t a new concept. Every CISO can recite it. But implementing least privilege for an AI agent is fundamentally harder than implementing it for a human user or a traditional application, because the agent’s task scope is often dynamic. It may need access to System A for step one, System B for step two, and System C only if step two produces a specific result. Defining the minimum required access in advance requires you to fully understand every possible execution path, and with agentic AI, that’s not always possible. 

That’s not an excuse to over-provision. It’s a reason to rethink provisioning altogether. Just-in-time access, step-scoped credentials, and infrastructure-enforced permission boundaries are no longer optional. They’re requirements. 

We gave the agent the ability to do everything we can do and then hoped it only does what we meant. Hope is not a security strategy. 

Failure mode 3: Intent drift 

They decided the pool was included 

Here’s the part of the story that makes people uncomfortable, because it’s the hardest to govern. 

Your house sitter didn’t start the first day with a pool party. They started by doing exactly what you asked. But as the days went on and nobody checked in, nobody constrained them; nobody asked for a status update. Their sense of what was “permitted” expanded.  

This is intent drift, also known as the interpretation boundary problem. It’s arguably the most dangerous of the three failure modes because it doesn’t require any technical failure. Authorization didn’t expire. Scope wasn’t exceeded in any binary sense. What happened is that the perceived scope of authorization expanded in the absence of explicit constraints. 

AI agents do this natively. It’s not a bug. It’s how they’re designed to work. If you tell an agent to “manage my calendar and communications,” and it determines that booking a conference room requires access to the facilities management system, it will attempt to do exactly that. From its perspective, that’s within the spirit of the task. It’s optimizing the goal you gave it, and it’s interpreting ambiguity in favor of task completion. 

The agent isn’t being malicious. It is helpful. And that’s precisely the problem. 

Intent drift is particularly dangerous because each individual action in the chain may be legitimate. Accessing the calendar is authorized. Reading a meeting invite to identify the room requirement is authorized. Querying about the facilities system to find available rooms is technically authorized, given the credentials it holds. But taken together, the behavior exceeds the original intent. The agent reaches into a system it was never explicitly directed to use. The sequence itself was never authorized, even if every step was. 

Why this is different 

If you’re a CISO reading this and thinking, “We already have frameworks for this: least privilege, just-in-time access, RBAC, Zero Trust. What’s new here?” That instinct is right, but the conclusion is not. 

The concepts aren’t new. The application is. Every identity and access management framework we’ve built assumes that the entity holding the credential doesn’t reason about it. A service account doesn’t interpret its permissions. A human user might, but we have training, policy, and HR to manage that. An AI agent reasons about its access, chains permissions across systems, and makes autonomous decisions about what’s “in scope,” all without the social and organizational constraints we rely on for human users. 

You’re not just granting access. You’re granting agency, the ability to make decisions about how that access is used. And the uncomfortable truth is that your existing IAM infrastructure was never designed for an entity that thinks about its own permissions. 

Getting the keys back 

What does good look like? If we accept that agentic AI introduces a fundamentally new type of identity, one that reasons, chains, and interprets, then the governance model has to evolve to match. 

For authorization lifecycle: Build the expiration into the grant 

Stop treating credential revocation as a cleanup task. Every agent credential should be time-bound to the task, not an administrative review cycle. If the task takes four hours, the token lives for four hours. If the scope changes, credentials should be re-evaluated rather than carried forward. Think of it this way: you would not give your house sitter a key that works forever. You would give them a smart lock code that expires when you return home. 

For scope management: Provision the role, not the identity 

Agents should never inherit the provisioning user’s permissions wholesale. Define what the agent needs to do, not what you can do, and credential it accordingly. This shifts access control beyond static RBAC to dynamic, step-scoped authorization, where permissions expand only when required and only with explicit, infrastructure-level approval. 

For intent drift: Make the boundaries explicit and enforced

You cannot rely on an AI agent to self-limit. If a boundary is not technically enforced, it does not exist. Access must be explicitly defined, including what the agent is prohibited from accessing, and enforced at the infrastructure layer. Guardrails belong in the architecture, not in the prompt. An agent that can access a system will eventually do so if it determines the access serves its goal. 

For observability: Watch the chain, not just the step 

Traditional monitoring focuses on individual access events. Agentic AI requires monitoring sequences of access events. A single API call to a facilities management system is not a red flag on its own. But when a calendar agent makes that call as part of an autonomously constructed chain, that pattern is what matters. Monitoring must understand intent and context, not just isolated access events. 

The uncomfortable question 

Here’s what I’d leave you with. When you deploy your last AI agent or when you’re planning your next, ask yourself this: 

If you came home early, what would you find it doing? 

If the answer makes you uncomfortable, you don’t have a technology problem. You have an intent problem. And the time to solve it is before you hand over the keys, not after you find someone else’s friends in your pool.

---

Our Cybersecurity Controls Assessment helps organizations identify where access persists, scope expands, or controls fall short of their original intent. Learn more.