Governance is not a switch you turn on after go-live.
Controls added late get bypassed, because bypassing them is cheaper than complying with them. This page covers how identity, permissions, digital-employee accountability, content safety and audit evidence are designed into the agent platform — and where our own limits are.
Identity first
Authentication, SSO and RBAC as the base of everything else
Agents as staff
Departments, roles, KPIs and offboarding for digital employees
Layered defence
Firewall, sensitive-word filters, injection defence, DLP
Evidence
Tamper-resistant logs, retrievable by page or OpenAPI
If governance was not designed in, it does not exist
A control bolted on after an agent estate is live is a speed bump, not a control. It is bypassed through a second path, a shared link, a copied prompt, or a quiet request to one admin. The only controls that hold are the ones that were designed in before the first agent was published.
This is the first question we ask in any governance review: can you name the person and the role that authorised this agent to do this thing to this data? If the answer is "the IT team enabled the workspace", you do not have governance. You have access.
Enterprise agent governance has a specific difficulty that ordinary application security does not: the thing being governed is not code, it is a non-deterministic worker with tool access and knowledge access. Permissions therefore have to be attached to the agent itself — its knowledge scope, its tool scope, its channel scope — not just to the human who happens to be talking to it.
- Identity before authorisation. Authentication, single sign-on and role-based access control are the floor, not the differentiator.
- One permission model for people and agents. If a digital employee cannot be granted, reviewed and revoked the way a person is, you cannot audit the estate at all.
- Separation of authorisation from configuration. Knowledge bases, plugins, models and agents are granted independently, so a role with agent access does not silently inherit data access.
- Evidence as a by-product of normal operation. Audit trails are not generated for the auditor; they are generated because the system runs that way, so they are complete when someone asks.
- Controls that assume the operator is busy. Anomalies are surfaced, not filed. If a permission change outside working hours does not generate an alert someone reads, it is a log entry, not a control.
Where agents break ordinary access control
A conventional application has a fixed menu of actions. An agent has a plausible space of actions, which is why permissions have to be scoped to the work rather than to the screen.
| Failure | What it looks like in an agent estate |
|---|---|
| Scope creep | An agent given a broad knowledge scope "just in case" starts returning content the role was never cleared for. |
| Ambient authority | A tool plugin connected for one workflow becomes callable by every agent in the space. |
| Orphaned agents | Agents created for a project outlive it, still holding permissions, still reachable, owned by nobody. |
| Privileged persona | A single agent holds the union of several people's access, with none of their accountability. |
| Unlogged egress | Answers fetched from a connected system, with no record of which agent asked or on whose behalf. |
Every row above is a design decision, not a product feature to bolt on. We build the estate so these cannot happen quietly — and we will show you the configuration, not just assert the outcome.
Governance in numbers
Identity, capability, data, output, evidence
The agent inherits the employee's, and nothing more
Leave, stay, or be minimised before it moves
Designed in from week one, not assembled at audit time
The base layer: who you are, and what you are allowed to reach
Five layers. Every enterprise agent estate needs all five, and most pilots have two.
The base layer: who you are, and what you are allowed to reach
Authentication, single sign-on and role-based access control, then workspaces, members, roles and post-level permission binding on top of them.
Authentication, SSO, RBAC
User identity authentication with single sign-on and role-based access control. Roles are not a flat permission list — they are composed of permission points that can be granted, withheld and reviewed.
Workspace and space isolation
Work is organised into workspaces and spaces, each with its own membership and role set. Public spaces support shared collaboration; private workspaces keep restricted work — and its knowledge — inside a boundary.
Membership lifecycle
Add members by phone number or email, assign their workspace, import in bulk for large onboarding waves, and activate accounts as people join. Offboarding removes the person; the same discipline applies to agents.
Role design is where most estates go wrong
Most role models are written for applications, where a role corresponds to a job. In an agent estate, a role corresponds to a capability bundle — and the question for the security team is not "what is their job title" but "which of these actions does this person need to be able to perform, and which agent needs to perform it on their behalf".
Two design choices in the platform make this tractable. First, permissions are bound to a role, and a role carries a specific set of permission points, so the mapping from person to capability is explicit and auditable. Second, a single employee can be bound to multiple roles, which is what the dual-hat (兼任) case actually looks like: someone who is a developer in one function and an operator in another should hold both, not a compromise of one.
Least privilege, concretely. Out of the box, ordinary members should not hold data export or API key management — those are the permissions that turn a compromised account into a data incident. Withdrawing them by default, and granting them to a named role, is the whole practice.
Binding permissions to posts
A worked example of how permission points map to a role set.
| Post | Permission points granted |
|---|---|
| Developer | Agent development, channel configuration, version publishing |
| Operator | Message reply handling, data viewing, user tag configuration |
| Ordinary employee | Invocation of designated agents only — no build, no publish, no export |
| Dual-hat (兼任) | Developer role and Operator role bound to one account, both auditable separately |
Digital employees are managed as employees, not as software
Give an agent a department, a post, a set of responsibilities and a KPI, and it becomes something an organisation can actually run — with the same RBAC system, the same review cycle and the same offboarding discipline as the people it works beside.
One permission model, two kinds of worker
An agent is assigned to a department and a post, with defined responsibilities and access rights, and it sits in the same RBAC system as your people. That is what makes the estate auditable: there is one place to ask "who can do this", and the answer covers humans and agents together.
Department and post
Ownership is structural, not a note in a description field.
Responsibilities and KPI
An agent can be held to a measured target the way a team can — which is also how you catch agents that are technically alive and operationally useless.
Shared RBAC
The same role, permission-point and channel-grant machinery applies to agents and employees.
Batch onboarding, and the hard part: offboarding
Large estates are provisioned and decommissioned in batches: agents onboarded for a project, agents retired when it ends, and permissions recovered when an owner leaves. General-purpose agent frameworks do not model this, because they assume you will delete what you no longer need — which is exactly what you forget.
Batch entry
Stand up a cohort of agents against a role set without a click per agent.
Batch exit
Retire agents and strip their grants in one operation, leaving an auditable trail.
Permission recovery
Reclaim access from departed staff and retired agents as a first-class operation, not a cleanup task.
Why this is the differentiator. Treating an agent as a licensed seat with a chat box makes it invisible to the org chart, to access review, to attrition analysis and to the budget conversation. Treating it as a digital employee with a post and a KPI makes it visible to all four — and it is the only way the number of agents you run can be governed as an estate rather than discovered by accident.
Digital employees are managed as employees, not as software
This is a management decision, not a technical one. The organisations that get this right treat their agent estate the way they treat a new operations team — because that is what it is.
- Version number as identity
- Deployed when ready
- Monitored for uptime
- No job description
- No performance record
- Retired when inconvenient
- Named role with a job description and explicit non-goals
- Onboarded — with a curriculum, not just a deployment
- Supervised by a named human, on a stated frequency
- Evaluated against a threshold set by the business
- Has a capability record and a cost per task
- Has a retirement plan, including what happens to its knowledge
Authorise the capability, not the conversation
Knowledge bases, plugins, models and agents are granted independently. An agent that can be invoked does not thereby gain access to every corpus, every tool and every model in the tenant.
Fine-grained, graded control means four separate authorisation surfaces. They are separate on purpose, because they fail differently: a mis-scoped knowledge grant leaks documents, a mis-scoped plugin grant lets an agent act, a mis-scoped model grant burns budget or bypasses a routing policy, and a mis-scoped agent grant opens a workflow to the wrong population.
Two operational rules follow. First, the permission an agent exercises to call tools or query knowledge is configured by the administrator, not inferred from the human who triggered it — so an agent's reach is explicit and reviewable. Second, department-level data isolation keeps a team's knowledge and data out of another team's answers, which is the control most often missed in shared workspaces.
For group-structured organisations, a multi-tenant operating edition exists to manage a business with multiple entities — group-level standards, entity-level administration, and data held per entity — rather than pretending one flat workspace can express a group.
- Knowledge bases — granted per corpus, per department, per agent
- Plugins — granted per tool, and often per channel the agent is published to
- Models — authorised separately from agents, with quota and rate limits
- Agents — who may invoke, publish, edit and publish to which channel
Where the grants sit
| Surface | Question it answers | Failure if mis-set |
|---|---|---|
| Knowledge | Which corpora may this agent read? | Content disclosure beyond the role |
| Plugin | Which systems may it act on? | Unauthorised action with real effect |
| Model | Which models may it call, under which quota? | Cost exposure, routing policy bypass |
| Agent | Who may invoke or publish it, to which channel? | Unreviewed function reaches the business |
| Channel | Where may it appear and be granted? | Grant applied where none was intended |
Authorise the capability, not the conversation
The risk is not what an individual prompt says. It is what the agent is capable of doing. Authorise the capability and the conversation follows from it.
Autonomous with sampled review
Low sensitivity, low materiality. The agent proceeds; a sample is reviewed. This is where most volume should sit.
Full human approval
High materiality. A person signs off every action. Slower, but this is where the risk actually lives.
Private processing, no data egress
Sensitive data, low materiality. The processing stays inside your boundary; only the conclusion leaves.
Both controls, always
Sensitive data and high materiality. Private processing plus human approval, plus a fuller evidence pack. Expensive, and correctly so.
Encryption, sandboxes, and data that does not need to leave
The strongest control available to an enterprise is not a rule about what an agent may not do — it is the architectural fact that the data was never in reach.
KMS-encrypted transport
Data in transit is protected through a key management service, so key custody and rotation are handled as an infrastructure concern rather than an application concern.
Trusted container sandbox
Agent code and tool execution run inside isolated sandboxes, so an external intrusion or a careless tool call does not become a path to internal data. Isolation is per execution, not per tenant.
Data sovereignty
Under private deployment, knowledge and data stay inside your network. In hybrid topologies, DLP controls govern what may cross the boundary, so the split is deliberate rather than accidental.
Privacy-preserving retrieval
Federated retrieval lets inference complete without the data leaving its domain — the answer travels where the data is not.
Tamper-resistant audit trail
Model calls, tool access, data reads and human actions are all logged, with a one-click export path. Log entries are records, not suggestions.
Operational audit over OpenAPI
Audit logs are retrievable through the console and programmatically via OpenAPI, so monitoring, SIEM integration and periodic review are engineering tasks, not exports by hand.
Read this before the security questionnaire. The controls above are platform capabilities we can demonstrate. Whether they constitute compliance for your regime depends on your architecture, your data classification and your own operating procedures — a control that is enabled but not monitored is not a control, and a control that is monitored by a person who leaves is a control with a single point of failure.
What comes out of the model matters as much as what goes in
A large-model application firewall, layered sensitive-word filtering, input filtering against prompt injection, and customisable industry rules — with publication review as the last gate before anything reaches users.
Large-model application firewall
Multi-layer interception covering leakage of confidential content, non-compliant output, and attempts at unauthorised data access. The point is not that every attack is stopped; it is that attacks are inspected at more than one stage, so a single missed check is not decisive.
Sensitive-word filtering, three layers
A built-in word list, your own custom word lists, and an optional model-based second pass. The custom list is the one that matters, because the words that are unacceptable in your industry are not on anybody's generic list.
Input filtering against prompt injection
Input filtering intercepts the classic pattern — instructions embedded in user content that attempt to override the system prompt or exfiltrate it. It is a filter on a moving target, and we describe its limits in the next section.
Custom industry compliance rules
Rule sets that reflect your regulatory reality rather than a generic baseline — for example anti-fraud constraints in financial services or confidentiality rules in government deployments.
Publication review workflow
Bringing agent release into a managed, reviewable process, so what reaches users has been through an approval step rather than appearing because someone clicked publish.
Model control, separate from agent control
Models are authorised independently of agents, with quota and object-level rate limits that also apply during evaluation runs — so testing cannot quietly consume production capacity.
Filters are one control, not the control
Output filters are a safety net, and a safety net is not a plan. We design deployments so that the primary guarantee is the agent never had the data, with filtering as a second layer over a narrower and more predictable surface.
| Layer | Acts on | Typical effect |
|---|---|---|
| Authorisation | Identity, role, workspace | Who may reach the function at all |
| Scope | Knowledge, tools, models, agents | What the work is allowed to touch |
| Sandbox | Execution | Containment of code and tool execution |
| Input filter | Prompt content | Intercept of injection-style instructions |
| Output filter | Generated content | Leakage, violation, sensitive terms |
| Audit | Everything above | Evidence for review and investigation |
Evidence for the auditor, alignment with the frameworks
Permission changes and staff operations are retained and retrievable, anomalies can be raised as alerts, and the control set maps to the international AI governance frameworks that enterprise buyers are asked about.
Permission operations leave a record
Every permission change and every staff operation is retained, and anomaly rules can be configured to raise alerts on behaviour that should not be routine — permission edits outside working hours, bulk authorisation grants, or a sudden change in an agent's scope. Alerts matter more than logs: a log reviewed after the fact tells you what happened, an alert tells you while it is still reversible.
- Non-working-hours permission changes — flagged, because legitimate administration happens in working hours
- Bulk authorisation events — flagged, because small changes rarely look like attacks and bulk ones frequently are
- Least privilege as a default — ordinary members hold neither data export nor API key management unless a named role grants them
- Retrieval by API — audit data flows into your monitoring and reporting pipeline rather than into a console someone remembers to open
What we deliver is a management system, its evidence and its controls. We do not certify you, and we will not represent a configuration as a compliance certificate. Mapping to a framework is a shared exercise over real evidence, and the evidence is what these controls produce.
Framework alignment
What the platform provides against each framework, stated in terms of systems and records rather than claims of conformity.
| Framework | What we provide |
|---|---|
| ISO/IEC 42001 AI management system | A management system for AI assets: inventory of agents and their owners, defined controls, review and release processes, and retained records of operation |
| ISO/IEC 23894 AI risk management | Risk controls at the point of work — scoped knowledge and tool access, permission boundaries, content filtering, full-chain logs for post-incident analysis |
| ISO/IEC 38507 AI governance | Authority and accountability structures: digital employees with departments, roles, responsibilities and review, and change evidence for what was published |
| NIST AI RMF | Govern, map, measure, manage functions supported by evaluation, observability, permission records and configurable alerting |
| EU AI Act | Technical documentation and logging capability — risk classification of use cases, human oversight points in workflows, and record-keeping that can be produced on request |
Framework versions and applicable articles change. We confirm the current mapping against your intended use cases during evaluation, in writing, with the specific controls referenced.
Evidence for the auditor, alignment with the frameworks
We do not sell a certification. We design the operational record that makes certification straightforward when you need it.
| Framework | What it asks of you | Where we engage with it |
|---|---|---|
| ISO/IEC 42001 | An AI management system — policy, objectives, roles, and a documented improvement loop | We help you design the management system, then evidence it from operational records |
| ISO/IEC 27001 | Information security management, extended to cover agent-held data and agent authority | We extend your existing ISMS scope rather than starting a parallel one |
| EU AI Act risk classification | Whether your system is limited, high-risk or prohibited, and what obligations follow | We help you classify, document, and meet the transparency and record-keeping duties |
| Sector regulation | Whatever your regulator already requires — MAS, HKMA, FSS, SFC, EBA or equivalent | We map the supervision record your regulator expects onto the decision log you already keep |
| Internal audit | Evidence that a control operated, over a period, consistently | The evidence pack, produced continuously, is designed for exactly this |
What this platform does not do
A security page that only lists strengths is a brochure. These are the real limits, stated so you can plan around them.
No documented fine-grained model allow-list or deny-list screen
There is no clear productised interface for a granular model black-list or white-list. Model authorisation and quota exist; a visual per-model deny-list console does not. If your policy requires a hard catalogue of prohibited models, raise it during evaluation — we will verify what is actually configurable rather than describe a screen that does not exist.
Cross-system audit depends on the other system
Audit coverage inside the platform is complete. Coverage of actions that leave the platform — inside an ERP, a database or a business application — depends on those systems logging and forwarding their own events. We will name the integration points that need your team's involvement, because pretending otherwise wastes an audit cycle.
Prompt-injection interception rates are not a promise
Published interception rates for prompt-injection defences come from the cloud vendor's own testing and vary widely by model, attack family and configuration. Treat any such figure as a marketing claim, not a commitment. We will instead show you the filter configuration, the test cases we can run against your own prompt surface, and the residual risk we observe.
And one more, plainly. Enabling a control is not the same as operating it. We deliver the capability and the evidence trail; the discipline of reviewing permissions, tuning filter thresholds and chasing alert queues is yours, and we will help you build that discipline through the consulting and training practices rather than pretend a checkbox does it.
What this platform does not do
This platform does not make you compliant. It does not replace your risk function's judgement, your legal advice, or your regulator relationship. And it will not produce evidence for a period you did not operate it — records start when you start, which is precisely why the design has to be right on day one.
Five questions that settle whether you need this
Five yes-or-no answers. If you cannot answer the first three, the capability is not your bottleneck yet.
- Can you name the specific workflow this serves — not the department?
- Can you name the person accountable when it is wrong?
- Can you show me historical cases where a human did this task, so we can build an evaluation set?
- Can you tell me what this capability explicitly will not do?
- Can you tell me what it costs per task, and how you would reduce that cost?
What the first ninety days look like
The same shape on every capability. The content differs; the checkpoints do not.
| By day 30 | By day 60 | By day 90 |
|---|---|---|
| Baseline captured on your metric | Workflow running with a named approver | Metric moved, against the baseline you did not choose |
| Scope boundary documented — including what it may not do | Evaluation harness re-running on every change | Decision log reviewed by your risk function |
| Historical cases assembled for testing | Training delivered, completion in the LMS | Next workflow scoped from what we learned |
| Data lineage for every source the agent reads | Cost per task measured and modelled | Evidence pack complete and accepted |
What this page answers
Every topic below is covered in the sections above, and each links to the page that goes deeper on it.
Bring your role model. We will map it to the permission surface.
A working session where we take your actual job roles, your agent inventory and your regulatory scope, and show you exactly which permission points, grants and audit records each one requires — including where the answer is "you must build that control yourself".