The case for AgentProfile: 5 reasons why autonomous agents need their own profiles
The first instinct when a team stands up an AI agent is to hand it a login. Give it a service account, drop it into an existing IdP group, let it inherit the permissions of whatever human role it’s standing in for. That works for a pilot, but it’s the wrong foundation for what’s coming.
We want the agents we’re building to be autonomous and act on their own. They’re managed by people, but they operate as their own distinct thing in the organization. We even see teams giving them human-like names so it’s easier to refer to them.
While there is still a place for agents that assume a specific user’s identity to automate a task — user logs in, agent gets permission, does the task — this model breaks with the agents of the future and it breaks in a way that ordinary access controls don’t help with yet.
This week, we announced AgentProfile, giving every AI agent its own record of context, cost, and action, not a borrowed login from a person. Here’s the thinking behind why that had to be built from the ground up.
It’s the business process that matters, not the a UI
We organize human access the way we do for strong reasons. People go to college, get trained, and report into a hierarchy. An “accountant” and a “sales representative” are bundles of permissions we hand out because that’s how humans specialize. Role separation exists on purpose. The person who raises a purchase order isn’t always the person who approves it, because we build in separation of duties to reduce fraud or reduce errors. Job hierarchies are a control surface.
An agent doesn’t need this. It doesn’t specialize because it has the expertise of a degree or got onboarded and trained. It doesn’t need role separation to protect it from a conflict of interest it will never feel. So why would we define its privileges the same way we define a person’s?
The more useful frame is the process, the transaction. Users care about the UI: screens, forms, and workflows built around what a person can see and click. An agent doesn’t touch that layer. It reaches systems of record directly, increasingly through MCP, and what matters is the set of transactions it’s allowed to perform. Once you center on transactions instead of screens, the business process itself is open for redesign.
Agents are polyglots, don’t cast them in narrow human-defined roles
A capable agent is a polyglot – you don’t need to narrowly define them as a sales rep, an accountant, or a supply chain planner. Organizations already lose time to handoffs between roles.
Quote-to-cash for a repeat order. Today a reorder walks a queue: a sales rep builds the quote, sales ops signs off on the discount, finance runs a credit check, fulfillment confirms stock, and accounts receivable cuts the invoice. Five roles, four handoffs, mostly waiting. A single agent can price the order against the customer’s contract, check their credit against open receivables, confirm inventory, and release the order, pausing only when a value crosses a threshold a human still owns. That one workflow touches sales, finance, and fulfillment. No human holds all three roles, and no agent should need all three roles’ full access to run it.
Procure-to-pay exceptions. An invoice arrives that doesn’t match its purchase order. Accounts payable flags it, procurement pulls the contract, the requesting manager confirms the goods arrived, finance approves the variance. An agent can retrieve the PO and the goods-receipt record, compare terms, clear the variance when it falls inside tolerance, and route anything larger upward with the discrepancy already documented. That’s accounts payable, procurement, and line-of-business approval collapsed into one transaction path.
Employee onboarding. A signed offer today kicks off work in HR, IT, security, payroll, and facilities. An agent can create the identity record, provision least-privilege access to exactly the systems the role requires, enroll the person in benefits, and schedule orientation. The point isn’t speed alone. It’s that the “onboarding agent” is doing work that maps to no single job title, and pretending it’s an “HR user” or an “IT admin” either under-scopes it or hands it far too much.
Each of these is a process a business can reimagine because the constraint that shaped it, humans specializing and passing work between them, no longer applies. But reimagining the process for agentic AI means we also have to reimagine how we grant access.
A human is still responsible
None of this removes the human. Every agent should have a manager who carries ultimate responsibility for what it does, the same way a director owns the actions of the team reporting to them. Autonomy doesn’t cancel ownership.
It also doesn’t mean the agent runs unchecked. Where business policy would make a person stop and ask for sign-off, the agent stops and asks too. A refund above a set amount, a contract term outside the standard book, a change to a production system: each of these routes through an approval workflow to a human before it executes, exactly as it would for an employee holding the same authority. The agent runs on its own most of the time and pulls a person into the loop at the moments that warrant one.
What the agent does need is to be treated and governed as its own organizational entity: its own identifying characteristics, permission set, and policy boundaries. Those belong to the agent, not to a person whose access it borrows. The human owns the outcome and holds the approval lever when necessary. The agent holds a scoped, governed set of things it is allowed to do on its own.
What identity does, and where it stops
Existing identity tools don’t help much here, and we want to be clear why. An identity provider is a database of user records. It knows what humans exist, what departments they’re in, who they report to, and what groups they belong to. The group is the key payload. When a user signs in, the IdP passes the group to the downstream application, and the application grants the permissions tied to that group.
That handshake happens once, at login. The IdP does not sit in the path of the transactions that follow. It has no opinion on the third API call the session makes, or the tenth, or whether the record being modified should have been in scope at all. For a human clicking through a UI at human speed, the risk is more manageable. The blast radius of a mistake is bounded by how fast a person can work.
An agent removes that bound. It runs at the speed of computation around the clock. The velocity of transactional impact is high, and the agent’s model can decide to take an action it judges as correct from its inputs, without fear of being reprimanded. In that setting, handing an agent more privilege than the task requires is a live exposure that possibly executes thousands.
Least privilege means something different for agents
Narrow least privilege isn’t a nice-to-have for agents. It’s the only safe default, and that requires a foundational redesign, not one inherited from human roles.
An example the old model gets wrong
Say an agent should be able to look up a customer’s records and order history, and offer a rebate to an unhappy customer, but only if that customer’s payables are current. Model this with existing IAM and you’d give the agent a “customer service rep” group and an “accounts payable” group, and you’d be done. You’d also have granted it everything else those two roles can do. That’s far more than the task needs, and every extra permission is something the agent might exercise at machine speed while nobody’s watching the specific transaction.
Governing an agent doesn’t end at deployment
Once an agent is in production, further gaps are exposed with existing identity tools. It’s important to have a means to monitor and manage the agent. Every model call it makes and every system it reaches needs to be observable so you can ensure governance. It has to tie back easily to its profile, not force deep log inspections that are scattered across different systems and tools.
Every transaction an agent runs needs an access policy applied to it, and every transaction is worth seeing. Which systems it reached, which models it used, the volume of calls, the time of day, the patterns that don’t look right. You can’t get that from a login event in your IdP.
What we built: AgentProfile
Binding policy to the transaction, not the login
What we’ve built is a distinct agent profile record. Instead of a group that maps loosely to an application’s permission set, we bind system access policy directly, down to the individual tools exposed by the application’s MCP. The agent gets the specific tools it needs and nothing adjacent.
On top of that binding, you set the conditions under which each tool can be used. Discounts only for customers in the country markets you actually sell to. Reads allowed, but with the record shaped before it reaches the agent, credit card numbers redacted and sensitive fields stripped, so the agent operates on exactly the data it’s entitled to and no more. The rebate example stops being an over-provisioning problem as the agent can read order history, and it can issue a rebate without ever holding the full “accounts payable” role.
On the AI model side, we grant virtual key credentials to the agent, and allow you to govern which models the agent may connect to. You can apply the same data access policies here as well, where you can ensure that the agent never exposes sensitive prompt or response data to the AI.
With MCP access governed and model access governed, the credentials and the business rules both live with the agent. Your policy for what an agent can touch, under what conditions, with which models, sits in one place instead of scattered across application permission sets, key vaults, and hard-coded provider calls.
Finally, all of the agent activity is brought back centrally so you can ensure that the agent’s activities with models, tools and system data are per policy and observable. Furthermore agent token costs are calculated and visible so you may keep your autonomous agents within budget.
How AgentProfile works
Part of the Barndoor AI Agent Governance Platform
Every shift in software has needed its own security model. Legacy IAM was built for people, but it wasn’t built to govern this new paradigm. As my co-founder and CEO Oren writes,”We’re not trying to protect legacy ideas about identity, observability, governance and accountability that don’t make sense in this new context.”
AgentProfile is part of the Barndoor AI Agent Governance Platform, which tracks an agent from credentialing through deprovisioning. Available for select customers, so reach out to schedule a demo.
