Before AI Takes Action, Decide What It Is Allowed to Do

Consider a hypothetical billing dispute. A resident says a late fee is wrong. An AI assistant retrieves the payment history, spots a possible posting delay and drafts a response for the property manager.

Now suppose the assistant can also remove the charge and send the resident a confirmation.

That changes its role. It is no longer just helping someone investigate. It is adjusting an account and communicating a decision on the property’s behalf.

The adjustment might be correct. But correctness does not answer a separate question: was the system authorized to make it?

That is the issue behind permission-based AI. For this article, the phrase means defining what an AI system may access, recommend and execute. It is a working definition, not a certification or regulatory standard.

The distinction matters as AI tools move beyond drafting text. In its March 4, 2026, analysis, “How agentic AI can reshape real estate’s operating model,” McKinsey describes systems that connect to business software and carry out multistep workflows. Its proposed architecture separates the tools that execute work from the controls governing permissions, approvals and monitoring.

For property managers, the buying decision should include both. What can the tool do, and what prevents it from doing more than the operator intended?

Reading a record should not authorize changing it

A maintenance assistant might need a service request, a unit number and relevant work-order history. That does not mean it needs the resident’s complete financial record.

Likewise, an assistant investigating a disputed charge might need to read the ledger without having permission to edit it.

These are separate decisions, even if a vendor packages them inside one product.

NIST’s Agentic AI Identity and Authorization Project, which includes a concept paper published in February 2026, addresses how organizations can identify AI agents and control their access. The work is an ongoing effort to develop practical guidance, not a completed mandatory standard.

For an operator, a useful starting point is a plain-language description of each workflow:

• The properties it serves.
• The information it can retrieve.
• The records it can change.
• The messages it can send.
• The actions that require approval.
• The person responsible for changing or revoking its permissions.

Those boundaries should be established before the system receives access, not worked out after its first disputed action.

Give the system a specific job

“Handle maintenance” is too broad to serve as an operating instruction.

A narrower assignment would allow the system to collect the reported problem, retrieve relevant service history and prepare a work order. Dispatching a contractor, authorizing an expense and closing the request would each require a separate decision about authority.

McKinsey’s real estate framework makes this distinction explicit. Its action layer connects AI to operating systems to execute work. Its control layer manages permissions, approvals for financial transactions and policy exceptions, audit trails and monitoring.

That separation gives property managers a useful way to evaluate a demonstration.

Instead of watching only the completed workflow, ask the vendor to stop at each consequential step. Can the assistant prepare a vendor assignment without releasing it? Can it propose a credit without posting it? Can it work at one property without gaining access to the entire portfolio?

The answers reveal whether the operator can control the workflow or must accept the product’s default level of authority.

Match approval requirements to the consequences

Not every action needs the same review. A standard acknowledgment and a lease change should not pass through an identical process.

An operator could begin with three categories. These are suggested operating boundaries, not legal requirements.

Work the system can complete within approved limits

Examples include summarizing a service request, answering routine questions from current property information or acknowledging that a message was received.

Even a simple communication needs limits. “We received your request” does not make the same commitment as “A technician will arrive within an hour.”

The system should not promise a response time unless that promise falls within its assigned authority and is supported by reliable information.

Work the system prepares for approval

Proposed account adjustments, spending above an established limit and exceptions to standard policy are candidates for review.

The assistant can assemble the records and prepare the action. An authorized employee decides whether it proceeds.

The approval should make clear what will happen: which account will change, by how much and what the resident or vendor will be told.

Work reserved for designated staff

An operator could reserve final application decisions, accommodation determinations, lease changes and legal notices for appropriately authorized staff.

AI could help organize the supporting information without receiving authority to make the final decision.

This approach is consistent with McKinsey’s recommendation to match controls to risk, use role-based permissions and distinguish advisory outputs from executed actions. It does not establish what any particular housing law requires.

Show reviewers what they are approving

A button labeled “Approve” is not meaningful oversight if the employee cannot inspect the proposed action.

For a fee adjustment, the review should show the relevant transactions, the amount to be changed and the exact message that would follow. Missing information and conflicting records should be visible.

McKinsey recommends clear review points for higher-risk actions, indications of uncertainty and concise summaries of what a system did and accessed. It also emphasizes the ability to intervene when something goes wrong.

The workflow needs a rule for unanswered requests, too.

Does the action remain pending? Does it move to a backup reviewer? Does it expire? For consequential actions, a sensible starting policy is to hold or escalate the request rather than treat silence as approval.

Otherwise, a process designed to preserve oversight can turn into a queue that nobody owns.

Ask where the restriction is enforced

Telling an AI assistant not to issue credits is different from preventing it from posting an unauthorized credit.

In its June 3, 2026, analysis, “The State of Agentic AI in 2026: Companies Are Chasing, Few Are Catching,” Forrester recommends unique credentials, least-privilege access, logging and a named owner for each agent. Least privilege means providing only the access needed for the assigned task.

Those recommendations translate into specific questions for a vendor:

• Does the assistant have its own identifiable account?
• Can read access and write access be assigned separately?
• Can permissions be limited by property and task?
• Does the system block restricted actions before they occur?
• Can staff review the action, its supporting information and its approval?
• Can the operator promptly disable access?

Ask for a demonstration of a prohibited action, not just a successful one. Have the vendor show what happens when the system requests a record outside its assigned property or attempts an adjustment beyond its limit.

A polished response shows that the tool can communicate. A blocked action shows that a boundary is being enforced.

Assign an owner before expanding access

Each workflow needs someone responsible for its permissions, exceptions and performance.

That person does not have to approve every routine task. They do need the authority to investigate problems, change the workflow and suspend it when necessary.

Forrester recommends a named owner for each agent, along with bounded tasks, approval gates and rollback paths before expanding autonomy.

For a property-management team, that suggests starting with one defined workflow at a limited group of properties. Review what the system completed, what it escalated, what staff reversed and what remains unresolved.

Use those findings to decide whether it should receive more authority. The fact that another software connection is available is not, by itself, a reason to enable it.

Permissions also have limits as a safeguard. They establish what a system is allowed to do. They do not prove that its information is accurate or that an authorized action is appropriate. NIST’s project identifies broader concerns around data exposure and autonomous behavior, while McKinsey includes testing, monitoring and intervention alongside access controls.

Before enabling the next AI workflow, ask the vendor to show one action it can complete, one it must send for approval and one it cannot perform. Then name the person responsible for keeping those boundaries current.