Permission-aware AI agents: self-serve answers for budget owners

You give budget owners self-serve answers without giving them database access by putting a permission-aware agent in front of the data: the agent inherits each person's existing entitlements, answers only from what that person is already cleared to see, and returns a traceable number rather than a query result. The permission model lives in the platform, not in the prompt — which is the whole distinction between a safe agent and a fast leak.

This matters because the alternative is what most finance teams do now: field the questions themselves. Ad hoc asks are the tax finance pays for being the only team with the numbers, and it is heaviest in exactly the weeks finance can least afford it. Our 2027 budget season survey found two-thirds of finance leaders named either consolidating data or chasing inputs as the worst part of budgeting, and 92% lose evenings or weekends to the season.

Bottom line: the blocker on self-serve was never the interface, it was permissions. Compensation sits in the same model as the spend an owner legitimately needs, so "just give them read access" is a non-starter. A permission-aware agent solves it by answering inside each person's existing entitlements rather than widening them.

Why direct access is not the answer

Three reasons, and only the first is the one people expect.

Compensation lives next door to everything else. A department head needs their own spend, headcount and hiring plan. In almost every model, those sit in the same structure as salary detail for their team and often for peers. Granting the useful thing grants the sensitive thing unless permissions are enforced at the row and column level, which is what role-based access controls in FP&A tools exist to do.

Raw access produces wrong answers confidently. A budget owner querying the model directly does not know which version is the plan of record, whether a mapping changed, or that marketing spend has three definitions in the business. They will get a number, and it will be defensible from their side and wrong from finance's.

It moves the burden rather than removing it. Finance stops answering the question and starts reconciling the answers, which is worse. The reason this pattern keeps failing is that self-serve reporting solved the retrieval problem and left the definition problem untouched.

What permission-aware actually means

The phrase gets used loosely. Four properties separate a real implementation from a demo.

The second row is where most tools quietly fall short. Filtering after retrieval works until a model summarizes across a set it was allowed to read but not allowed to reveal, at which point the aggregate leaks the detail. If the vendor cannot say where in the request path the permission check happens, assume it happens late.

The third row is the operational one. A parallel permission model is a permission model that drifts, because nobody remembers to update it when someone changes teams. Aleph agents respect your existing data permissions, so a budget owner only sees the numbers they were already cleared for, and there is no second list to maintain.

The four prerequisites before agents touch the budget

Permissions are one of four. All four have to hold before you let an agent work inside a live plan.

1. Traceability. Every number resolves to a system, an owner, a date and a reason. An answer you cannot trace is an answer you cannot defend in a board meeting.
2. Deterministic output. The agent may reason probabilistically, but anything written to the model passes deterministic checks, and the same question returns the same answer every time. Conversation in, validated model line out.
3. Need-to-know by default. The agent can work across the whole budget without exposing it across the business.
4. Safe iteration. Owners change their minds as often as they like without touching the plan of record. Proposed is not approved.

Number two is the one finance teams underrate and auditors do not. A chat interface that produces a slightly different figure on a second asking is unusable for anything that reaches a board pack, however impressive the first answer was. Our guidance on AI accuracy and auditability and explainable AI for FP&A covers what to require, and it is the same standard whether the AI is answering a question or drafting month-end close commentary.

What good looks like in practice

The useful version of this is not a portal. It is an agent in the place where budget owners already work — Slack or Microsoft Teams — because a portal is a thing people have to remember to visit and a thread is not.

During budget season that agent does four jobs. It sends each owner a pre-filled packet built from their own actuals rather than a blank template. It answers their questions from their own numbers, in the thread, without finance in the loop. It checks every answer against that department's guardrail as it arrives. And it follows up with whoever has gone quiet, which removes the single most demoralizing task in the cycle.

Outside budget season the same capability handles the standing ad hoc load: what did we spend on contractors last quarter, is my headcount plan still funded, why did my line move. Those questions are individually small and collectively the reason finance has no time for analysis. AI agents for finance and FP&A covers the wider category; the budget-owner case is the one where permissions are the binding constraint rather than a nice-to-have.

Questions to ask a vendor

• Where in the request path is the permission check applied — at retrieval, or before display?
• Does the agent inherit our existing groups and roles, or does it need its own permission list?
• Can you show me the log for a specific answer, including which source rows fed it?
• If I ask the same question twice, am I guaranteed the same number?
• Can an owner propose a change without it reaching the plan of record?
• Which surfaces does this work in — Slack, Teams, spreadsheets, or only your web app?

Run these on your own data with a genuinely restricted test user, not an admin account. An admin account will answer every question beautifully and prove nothing, which is the most common way this evaluation goes wrong. Our demo questions guide has the wider list, and the evaluation guide has the scoring sheet.

One last framing worth holding onto: the goal is not to remove finance from the conversation. It is to remove finance from the mechanical part of the conversation, so the escalations that reach a human are the ones where the number and the plan genuinely conflict. That is the split agentic budgeting is built around — agents run the process, finance makes the calls.

The ad hoc ask, priced

Nobody tracks this, which is why it never gets fixed. Try the arithmetic on your own team. A mid-market finance team of five fields somewhere between fifteen and forty questions a week from the business: what did we spend on contractors last quarter, is this role still funded, why did my line move, can you pull the actuals for my board slide.

Most take five to twenty minutes, and the cost is not the minutes — it is that they arrive as interruptions during the exact weeks finance is trying to consolidate a budget. Twenty interruptions a week against a five-person team is the difference between having time for analysis and not. It is also invisible in every capacity plan, because it never appears as a project.

This is the same coordination cost that dominates budget season. Two-thirds of finance leaders in our 2027 budget season survey named either consolidating data or chasing inputs from other teams as the worst part of budgeting. Notably, when asked what they would hand to AI first, coordination came dead last — teams assume gathering and answering is a human-only job. It is the assumption worth revisiting.

Four architectures, four permission stories

How a tool is built determines what it can safely tell a budget owner. This is the part vendor demos skip.

Chat over a copied dataset. A snapshot is exported into a vector store or a separate database and the model answers from that. Fast to build, and the copy usually has no permission model at all, so anyone who can ask can see everything in it. Also stale by definition, which produces confidently wrong answers about a plan that has since moved.

Text-to-query against a warehouse. The model writes SQL and runs it. Permissions depend entirely on the credential it runs as — if that is a service account with broad read access, every user effectively has broad read access. Ask which identity executes the query.

Agent over the planning platform's own API. The agent calls the same interfaces a user would, as that user, so the platform's existing permission model applies without a parallel list. This is the pattern that holds up, and it is why the question of where the permission check happens is diagnostic.

Agent in a chat surface, backed by the platform. Same as above with Slack or Teams as the interface. The important detail is that identity has to map from the chat account to the platform account, or you get a permission model that is right in the app and wrong in the thread.

Our wider notes on role-based access controls cover the underlying model, and financial model audit trails covers the logging half. For the general category, AI agents for finance and FP&A sets out what these tools do beyond answering questions.

Rolling it out without a security review from hell

1. Pick one department and one question class. Marketing, and "what is my current spend against plan." Narrow enough that a wrong answer is obvious to the person receiving it.
2. Test with a genuinely restricted account. Not an admin. Ask it for another department's numbers and for salary detail, and confirm it declines rather than complies.
3. Turn on logging before users, not after. You want the log of the first hundred answers, because that is your evidence base for the wider rollout.
4. Publish what it can and cannot do. Owners who know the boundary stop testing it and start using it. Ambiguity is what generates escalations.
5. Review the escalations weekly for a month. Every question that reached a human is either a permission gap, a definition gap, or a genuine judgment call. The first two are fixable.
6. Then widen by department, not by question type. Adding departments tests permissions; adding question types tests the model. Do them one at a time.

Step five is where the value shows up. In most rollouts the escalation log reveals that a third of questions were definition problems — two teams meaning different things by the same metric — which no agent can fix and which finance can. Fixing those improves every report you produce, not just the agent's answers.