The infrastructure that determines whether agents can be trusted at scale
Deploying AI agents is not the hard part. The hard part is deploying them in a way your IT department, your legal team, and your facility managers can actually stand behind.
The final session of the Agentic Proptech Webinar Series goes into the infrastructure layer that everything else depends on: how to structure permissions so agents have exactly the access they need and nothing more, how to set operational guardrails that prevent unintended actions, and how to build an audit trail that gives your organisation full visibility over everything the agentic workforce does.
Rasmus Gorm Pedersen and Per Karlberg close out the series with a framework drawn from both the emerging global standards — OWASP Top 10 for Agentic Applications, the NIST framework, the EU AI Act — and from what ProptechOS has built and learned while running agents across its own internal operations and customer deployments.
What this session covers
– Why the security question is now unavoidable — as agentic AI moves from pilot to portfolio-wide deployment, IT departments, legal teams, and property owners are all converging on the same ask: prove it is controlled, auditable, and compliant
– What is new about agentic security — two specific risks that traditional IT security does not address: agents as an escalation path for bad actors, and agents going beyond their intended scope (“rogue agents”) — and how both are managed through permissions and guardrails
– Zero standing privileges and just-in-time security — how ProptechOS has moved to a model where agents have no access by default, and access is granted temporarily, task-specifically, and automatically revoked when no longer needed
– The EU AI Act risk framework — how to classify each agent by risk level (minimal, limited, high, unacceptable) and what administrative and technical policies that classification requires, including what is coming in the ProptechOS platform after summer
– Auditability as a non-negotiable — why every agent action, every agent-to-agent handoff, and every edit to an agent’s system prompt needs to be logged — and why the language-model nature of current agents makes this easier than it sounds
– How to organise an agentic workforce — grouping agents by domain, seniority, and risk level so that policy frameworks, oversight responsibilities, and audit practices can be applied at the right granularity
– Managing external agents — what happens when an agent from a vendor, supplier, or a property owner’s own Copilot Studio or Claude environment acts inside ProptechOS, and how ProptechOS maintains full auditability on its side of the fence
– Where to start — a practical first step: audit who currently has access to your OT systems, remove access that is no longer needed, and apply the same just-in-time principle to agents that you would to any other external actor
The three pillars of agentic governance covered in this session
Security
Agentic security builds on the IT and data security you already have — identity, access control, encryption, network security. What is new is that agents are now actors with privileges, not just passive consumers of data. An agent that can be convinced to take unauthorised action is a security vulnerability just like any other. Everything that reduces the exposure area of your data and systems — strong identity management, minimum privilege, rapid revocation — applies with more force in an agentic context, not less.
Guardrails and permissions
The minimum privilege principle applied to agents: give each agent access only to the data it needs, and agency only over the actions it is responsible for. A nighttime ventilation agent needs read access to sensor data and occupancy, write access to ventilation setpoints, and nothing else. A triage agent can read all incoming service objects but has no actuation rights.
The operational dimension matters as much as the technical. A guardrail is not only a data security boundary; it is also the rule that tells an agent when to stop and ask a human rather than act autonomously. That escalation path — the moment when an agent pauses and defers — is as important to safe deployment as any access control setting.
Auditability and maintainability
Every agent action logged. Every agent-to-agent conversation traceable. Every change to a system prompt recorded with who made it and when. This is a compliance requirement under the EU AI Act for higher-risk agents, and it is simply good operational practice for all of them. Because current-generation agents work in natural language, maintaining exact logs of what they see and produce is straightforward — and the same log that satisfies a compliance auditor is the one that helps your team understand what an agent did and why.
How ProptechOS implements this in practice
ProptechOS moved to zero standing privileges for its own internal agentic workforce. Agents start with no access to anything. When they are about to perform a task, they first describe exactly what they intend to do, with a reference to the task or work order that authorises it — analogous to the physical work order that gives a contractor access to a building for a specific job. Temporary privileges are granted, the task is performed, and access is automatically revoked.
This model was adopted in response to the agentic era — but the underlying principles were already there. Agentic AI does not require a different security architecture; it requires you to have the one you should already have, and to have it properly in place.
For external agents — agents built and operated by a third party acting on behalf of a property owner — ProptechOS ensures that any external agent can be registered as its own identity in the system, and that every action it takes inside ProptechOS is logged with full detail: what was done, to which asset, at what time, and with what outcome. The larger question of globally consistent trace IDs for cross-system agent chains is still emerging, but the principle of full auditability on each platform’s own side of the fence is already in place.
What the market is telling us
At the Realcomm/IBcon conference in San Diego, ProptechOS’s head of Customer Success; Gustaf Tivelius, observed that the US market has moved past the “what is it” phase entirely. No one at the booth was asking whether to adopt agentic AI. The questions were about how, when, and in what way — and everywhere, security, maintainability, and the ability to audit these systems were front-of-mind.
At a seminar in Oslo, with KLP Eiendom and Skarpe, the largest universities in the room confirmed the same pattern: data ownership and governance are not theoretical concerns. They are live procurement and contract questions, with real regulatory weight behind them.
The organisations that get this right — that build the permission and audit infrastructure before it becomes an incident — are the ones that will be able to scale agent deployment without pulling back. The first serious agentic failure in an organisation that has no governance layer is typically the thing that delays the programme by twelve months.
Practical steps to take after this session
Audit your current access — take a look at who has access to your OT systems and what they are authorised to do. Third-party consultants often retain access well beyond the project that required it. That is the starting point for a just-in-time model.
Classify your agents by risk level — use the EU AI Act’s four-level framework (minimal, limited, high, unacceptable) to assign a risk level to each agent you have or are planning to deploy. Different risk levels require different administrative and technical policies.
Define the escalation path for each agent — for every agent in your workforce, document the conditions under which it should stop and ask a human rather than act autonomously. This is as important as the permission scope.
Make the audit trail a requirement, not an afterthought — before deploying any agent that performs real-world actions (controlling set points, creating work orders, modifying data), confirm that every action will be logged with identity, time, action, and outcome.
Frequently asked questions
Q: Is agentic security fundamentally different from regular IT security?
Not at its foundation — identity, access control, encryption, and network security still apply. What is new is that agents are now actors with privileges, which introduces two specific risks that traditional IT security was not designed for: an agent being used as an escalation path by someone who does not have direct access, and an agent going beyond the scope of its instructions. Both are addressed through the permission and guardrail framework described in this session.
Q: What is zero standing privileges and why does it matter for agents?
Zero standing privileges means an agent has no access to any system by default. Access is requested task-by-task, granted temporarily, and automatically revoked when the task is complete. This dramatically reduces the exposure area compared to a model where an agent has persistent broad access. It also creates an automatic audit trail, since every access request and grant is a logged event.
Q: How does the EU AI Act apply to building agents?
The EU AI Act classifies AI systems by risk level. Most building automation agents — energy optimisation, triage, predictive maintenance — will fall into the minimal or limited risk categories, which have lighter compliance requirements. Agents that make decisions with significant consequences for individuals may be classified as high risk, which requires more formal documentation, testing, and audit processes. ProptechOS is building automated risk-level classification into the platform, which will be visible after summer.
Q: What happens when an external agent — from a vendor or our own system — acts inside ProptechOS?
External agents can be registered as their own identities in ProptechOS, with exactly scoped permissions. Every action they take inside the platform is logged in the same way as actions taken by ProptechOS’s own agents: what was done, to which asset, at what time, and with what outcome. ProptechOS cannot control how the external system logs its own side of the interaction, but it maintains full auditability for everything within the platform.
Q: We are not yet running agents. Is this session relevant for us?
Yes — arguably more so. The organisations that define their permission and governance model before agents are deployed make fewer mistakes and encounter less resistance from IT and legal. Building the framework while the programme is still small is faster and cheaper than retrofitting it after the first incident.
Q: What is the human-in-the-loop model, and when should agents escalate?
Every agent should have a defined scope of autonomous authority and a defined escalation condition. Inside its scope, it acts. At the boundary, it stops, presents its reasoning and proposed action, and waits for human approval. As you observe agent behaviour over time and trust develops, you can extend the autonomous boundary. Starting narrow and expanding is always better than starting broad and having to pull back.
See the permission and guardrail architecture in ProptechOS
Book a demo and we can walk through how identity management, just-in-time permissions, and agent auditability are implemented in a live portfolio context.