Picture this: your AI agent wakes up before you do. It reads your emails, scans your calendar, pulls up the latest notes from your CRM, checks open support tickets, and has a polished briefing waiting for you when you sit down at your desk. No prompts required. It just happened.
That sounds like the future of work. And it is. But here's a question most people aren't asking yet: when your AI agent did all of that, whose keys did it use to get in?
When you watch an AI agent demo - and there are a lot of impressive ones out there - it almost always looks seamless. The agent connects to your tools, takes actions, produces results. Magic.
What you're not seeing is that most of these demos run using the developer's own credentials. Full access, no restrictions, one user, one machine. It works beautifully. But it's a bit like showing off a self-driving car on a closed test track with perfect weather and no other vehicles. The real world is messier.
In a real enterprise environment, AI agents don't work for just one person. They run for entire teams, often while people are offline, asleep, or away from their desk. They touch Salesforce, email, Slack, internal databases, finance systems. Each of those systems has its own rules about who can see what, and what actions they're allowed to take. That's where things get complicated.
When an AI agent takes an action - sends an email, updates a record, approves a document - is it acting as you? As the company? As some generic system account? This distinction matters a lot, both legally and operationally. If something goes wrong, "the AI did it" isn't an audit trail.
Most agents today have more permissions than they need - because it's easy to just hand over a master key and skip the work of defining limits. That's a shortcut that creates real risk. A well-designed agent should only be able to do exactly what it needs to do for a given task and nothing more.
This is the one that should make everyone pay attention. The answer, in too many current systems, is: yes. Credentials get passed into the AI's "thinking space," which means they flow through logs, debugging tools, and monitoring systems - none of which were designed to store secrets. The right architecture means the agent can use a credential to take an action without ever seeing the actual key. Think of it like a valet who can drive your car but doesn't know your home address. The car moves; the information stays protected.
A proper audit trail doesn't just say "an agent updated the contract." It says: "The scheduling agent, acting on behalf of Sarah in the enterprise accounts team, updated the contract renewal field in Salesforce at 7 am EST, and here's the authorization chain that made that possible." That's the difference between compliance you can defend and compliance theater.
The shift from "AI assistant you talk to" to "AI agent that acts for you in the background" is enormous. And most of the conversation in the market right now is still focused on capability: what can this agent do?
The harder, more important question is: what has it been given access to, and under what rules?
As AI agents become embedded in business workflows - handling procurement, managing customer relationships, processing invoices, coordinating teams - the organizations that get this right will be the ones that can scale AI with confidence. The ones that don't will eventually face a security incident, a compliance failure, or a trust breakdown that sets them back significantly.
At Vertesia, this is something we've thought about deeply. Identity and permissions aren't features we're planning to add later. They're the foundation everything else is built on.
If you want the full technical picture - including how credential injection actually works, the different types of agent-triggering scenarios (interactive vs. background vs. no-user-at-all), and what a proper identity stack looks like under the hood - our CEO Eric’s original article is the place to go.
No Secrets for Agents: Designing Identity and Permissions for the AI Era