Most firms deploying an AI agent answer the questions in the wrong order. They ask whether the model is accurate enough, decide that it is, and then hand it a login. AI agent permissions in commercial real estate are almost always set by inheritance: the agent runs as an analyst, so it can reach everything an analyst can reach, whether or not the work requires it. That is not a security decision. It is the absence of one. The correct unit of permission for an agent is not a person. It is an action, graded by whether the firm can undo it.
Key Takeaways
An agent running on a person's credentials inherits that person's entire blast radius. The task needs two permissions. The login conveys a dozen or more, and every unused one is reachable.
The OWASP GenAI Security Project ranked Identity and Privilege Abuse third in its Top 10 for Agentic Applications, published December 2025, describing agents that misuse inherited permissions and delegated trust to reach systems beyond their intended limits.
NIST's National Cybersecurity Center of Excellence opened a concept paper in February 2026 on software and AI agent identity and authorization, treating identification, authorization, delegation, and auditability as unresolved problems rather than settled practice.
An agent's instructions arrive inside its inputs. In the InjecAgent benchmark, a ReAct-prompted GPT-4 agent followed instructions injected through tool output in 24 percent of 1,054 test cases, rising to 47 percent when the injection was reinforced.
The permission test is not trust. It is reversibility. An agent may act alone where the action can be undone inside the firm, without a counterparty ever seeing it.
Why do AI agents end up with the wrong permissions by default?
Because permission systems were built to describe people, and an agent gets deployed as one. It receives a service account modeled on a role, inherits every capability attached to that role, and uses two or three of them. The excess is not dormant. It is standing authority waiting for an instruction.
Consider the arithmetic on a single agent. A screening agent has one job: read inbound offering memorandums and write a screening record. Work the required permissions from the task. It needs to read one mail folder and insert rows into one table. That is two capabilities. Now work the permissions a standard analyst identity conveys at a mid-sized acquisitions shop, using an illustrative inventory of systems the role touches.
Capability conveyed by the analyst login | Required by the screening job |
|---|---|
Read the deal mail folder | Yes |
Write to the screening table | Yes |
Read and edit every deal folder in the document repository | No |
Delete files from the repository | No |
Read and write the pipeline of record | No |
Read accounting and the general ledger | No |
Send from the shared deal address | No |
Send documents for electronic signature | No |
Read the firm's data room invitations | No |
Read investor and LP correspondence | No |
Export contact and broker lists | No |
Modify calendar entries firm-wide | No |
Two required, ten excess, in a worked example built from stated inputs. The excess is the part that matters. Each unused capability is a path, and the agent does not know which paths it is supposed to leave alone. Nothing in the deployment told it. The role told it everything was fine.
This is the same mistake firms make with the inbox, one layer deeper. The objection to connecting AI to the deal inbox is a scoping objection: one grant covers every message. The agent version is worse, because read access ends at exposure and an agent's permissions end at action.
What makes agent permissions different from ordinary software permissions?
A script's instructions come from its author. An agent's come from its input. In commercial real estate, that input is an unsolicited PDF from a broker nobody at the firm has met, a rent roll of unknown provenance, an email thread forwarded three times. Ordinary software cannot be talked into using a permission it holds. An agent can.
This is the part that makes existing procurement questions inadequate. A firm asks about encryption, SOC 2, and retention, all of which assume the threat comes from outside the workflow. Indirect prompt injection comes through the workflow. Instructions hidden in a document the agent was asked to read become instructions the agent follows, using permissions the firm granted on purpose.
The academic measurement is blunt. InjecAgent, published in Findings of the ACL, built 1,054 test cases across 17 user tools and 62 attacker tools and found that a ReAct-prompted GPT-4 agent followed injected instructions in 24 percent of cases, and 47 percent when the injected content was reinforced with a hacking prompt. The OWASP Top 10 for Agentic Applications lists Identity and Privilege Abuse as ASI03, covering inherited permissions during delegation, cached credentials, and the confused deputy pattern where one agent persuades a higher-privileged one to act for it.
Every other control assumes the agent is following your instructions. The permission boundary is the only one that still holds when it is following someone else's.
That reframes the deployment question. The issue is not whether a broker will hide instructions in an offering memorandum this quarter. It is that the firm's entire defense currently rests on nobody trying.
Which actions should an AI agent be allowed to take alone?
Actions that are reversible, internal, and attributable. Reversible means the firm can undo it in one step. Internal means no counterparty sees it. Attributable means the log records which agent acted, under what authority, from which input. An action that fails any one of the three needs a person between the plan and the execution.
Three tests, applied per action rather than per system, produce a permission map a principal can read.
Action | Reversible | Internal | Attributable | Verdict |
|---|---|---|---|---|
Extract lease fields into a draft abstract | Yes | Yes | Yes | Act alone |
Write a screening record for an inbound OM | Yes | Yes | Yes | Act alone |
Flag a deal as outside the buy box | Yes | Yes | Yes | Act alone |
Overwrite a field in the system of record | No, unless versioned | Yes | Yes | Propose |
Email a broker to request the rent roll | No | No | Yes | Propose |
Route an LOI or lease for signature | No | No | Yes | Human only |
Initiate or amend a payment instruction | No | No | No | Never |
Delete or archive a source document | No | Yes | Yes | Never |
Two things fall out of the table. First, most of the value in a CRE workflow sits in the top rows. Reading, structuring, comparing, and recording are reversible and internal, and they are also where the hours go. A firm can capture the majority of the benefit without granting a single irreversible permission.
Second, the bottom rows are not a maturity curve. They do not become safe once the model gets better. An emailed request to a broker is permanently outside the firm the moment it sends, and no model accuracy improvement changes that. This is the distinction between a model that extracts and one that acts, drawn as a permission line rather than a capability one.
How should a CRE firm scope agent access in practice?
Start from the task, not the person. Enumerate the smallest set of reads and writes the job requires, issue the agent its own identity rather than a human's, confine writes to objects the firm can version, and turn every action outside that boundary into a proposal a person approves.
Four rules cover most deployments.
Give the agent its own identity. An agent sharing an employee's credentials is untraceable by construction. The log says the analyst did it. NIST's NCCoE concept paper on software and AI agent identity and authorization, released February 2026, frames identification, authorization, access delegation, and auditability as the four open problems in exactly this area. The standards are still forming. The practice of borrowing a human's login should not wait for them.
Scope to the task and bound it in time. A screening agent gets the screening folder and the screening table, with a credential that expires. Standing access for a periodic job is a permission granted for the 99 percent of hours in which the job is not running.
Write to a staging layer, not the record. An agent that proposes into a review queue is reversible by definition. An agent that writes into the system of record is only reversible if the system versions the prior value, and most do not.
Make approval action-level, not blanket. A person clicking approve on a batch of forty is not reviewing forty. Gate the specific action classes that fail the reversibility test, and let the rest run unattended. This is what human-in-the-loop validation means in practice, and it is the opposite of asking a junior analyst to spot-check everything.
What does the audit trail have to record about an AI agent?
Four things: which agent acted, what authority it acted under, what input caused the action, and what the state was before. Most logging captures the first and the last. The middle two are what a committee, a lender, or an auditor asks for, and they break when an agent runs on borrowed credentials.
The failure is quiet. A log that records an analyst's name for an action taken by an agent is not merely incomplete, it is wrong, and it is wrong in a direction that assigns a person responsibility for a decision they did not make. That is a governance problem before it is a technical one. It is also the reason the audit trail is the first thing a diligence team asks about and the last thing a deployment builds.
Frequently Asked Questions
What permissions should an AI agent have in a CRE firm?
The smallest set the task requires, issued to the agent's own identity rather than an employee's, and bounded in time. In practice that means read access to one document source and write access to one staging table, with anything that leaves the firm or cannot be undone routed to a person for approval.
Can an AI agent be given access to the system of record?
Read access, yes. Write access only where the system versions the prior value, so a wrong write can be reversed in one step. If the platform overwrites without history, the agent should write to a review queue and a person should commit the change.
What is identity and privilege abuse in agentic AI?
It is the OWASP Top 10 for Agentic Applications risk ASI03: an agent misusing credentials, tokens, or inherited permissions to reach systems or data beyond its intended limits. It covers permissions inherited during delegation, cached credentials, and confused deputy attacks between agents.
Does a better model make broad agent permissions safe?
No. Accuracy and authority are separate properties. A more accurate model still cannot unsend an email to a broker or reverse a signature request. Permissions should be scoped to what the firm can undo, which does not change as the model improves.
Conclusion
The permission question gets treated as an IT detail to settle after the pilot proves value. It is the opposite. Firms that skip it are not deploying an agent with no permission policy. They are deploying one with the broadest possible policy, chosen by default, on behalf of a person who never agreed to it.
The discipline is small and available now. Work the permissions from the task instead of the role. Give the agent a name of its own. Keep the writes reversible and the sends human. A firm that does this captures the automation benefit on the work that is safe to automate, and keeps a clean answer for the lender, the committee, and the LP who eventually asks who approved this.