Trust Architecture
Role-Based Control
Freya is powerful. Who can direct her, approve her work, and see your data is governed with precision — by role and responsibility, so the authority that exists in your business is also the authority that exists in your AI operations.
- Layered roles
- Six dimensions
- Bounded authority
- Layered roles
- Admin, leadership, operators, view-only
- Six dimensions
- Data, initiation, approval, modes
- Bounded authority
- Thresholds & escalation by design
Section 01
The governance problem Antarious AI solves
Why access control in AI systems is different
In conventional software, access control manages who can view data and who can modify it. In an AI operating system for small business — marketing, sales, and finance — access control must answer a harder set of questions.
Who can instruct Freya to initiate a workflow? Who can approve the actions she prepares? Who can see the customer and pipeline data she is analysing? Who can modify the boundaries she operates within? Who can escalate decisions upward — and to whom? Who is accountable when something goes wrong?
These questions do not have simple answers in most organisations. They reflect real authority structures, delegation arrangements, departmental boundaries, and governance requirements that vary by role, by function, and by the nature of the action being taken.
Antarious AI role-based control is designed to encode those structures into the platform — so that the governance that exists in your business is also the governance that exists in your AI operations. Not approximated. Reflected with precision.
Section 02
The role architecture
Four foundational role layers
Every Antarious AI deployment is built around four foundational role layers. Within each layer, roles are customised to reflect the specific structures of your organisation.
Layer 1 — System administration
Who this is: Technical administrators responsible for the configuration and security of the Antarious AI deployment.
What they can do:
- Configure user roles and permission sets
- Manage integrations and data connections
- Set system-wide parameters and Freya agent configurations
- Access audit trails for system administration purposes
- Manage user accounts, access grants, and revocations
What they cannot do:
- Approve operational actions on behalf of designated approvers
- Modify audit records
- Access operational data outside their designated scope
- Override approval requirements for external actions
Layer 2 — Operational leadership
Who this is: Owners, directors, CMOs, GTM leads, finance leads, and equivalent senior decision-makers.
What they can do:
- Receive and action high-authority approval requests
- Access cross-functional dashboards and intelligence outputs
- Configure approval thresholds and escalation rules within their authority
- Commission strategic reports and briefings from Freya
- Set operational priorities and workflow parameters at the leadership level
What they cannot do:
- Modify system architecture or role configurations (without administrator involvement)
- Access departments or functions outside their designated scope
- Approve actions that require a different designated authority
Layer 3 — Operational users
Who this is: Team leads, marketing managers, SDRs, operations staff, finance coordinators — the people doing the day-to-day work that Freya supports.
What they can do:
- Initiate workflows within their designated scope
- Review and approve actions within their authorised threshold
- Access data and dashboards relevant to their function
- Communicate with Freya through natural language queries within their permission scope
- Escalate decisions that exceed their approval authority
What they cannot do:
- Approve actions above their configured authority threshold
- Access data from functions outside their scope
- Modify workflow configurations or approval routing rules
- View other users' approval queues or decision records
Layer 4 — View-only and external access
Who this is: Board members, external auditors, advisors, agency partners, investors under NDA, and others who require read access to specific outputs or records without operational involvement.
What they can do:
- Access specified dashboards, reports, and data views within their granted scope
- Export records and reports within their permission level
- Submit queries to Freya where this is configured (for example, an advisor reviewing GTM performance summaries)
What they cannot do:
- Initiate or approve any operational action
- Access data outside their explicitly granted scope
- Modify any system configuration or record
Section 03
Permission dimensions
The six dimensions of role configuration
Each role in Antarious AI is defined across six dimensions. Taken together, they produce a precise governance profile for every user — not a rough approximation of their authority, but an accurate reflection of what they should and should not be able to do.
Dimension 1 — Data access scope
Which data sources, dashboards, and intelligence outputs can this role see?
Scoping options include:
- Function scope: Access limited to data from a specific department, team, or business unit (marketing, sales, finance)
- Geography scope: Access limited to a specific region, market, or delivery area
- Project scope: Access limited to a specific campaign, product line, or initiative
- Full scope: Access across all connected data sources (typically reserved for owners, senior leadership, and system administrators)
Data access can be further restricted by sensitivity classification — ensuring that personally identifiable customer information, financial data, or commercially sensitive intelligence is accessible only to roles with a legitimate need.
Dimension 2 — Workflow initiation authority
Which workflows can this role instruct Freya to begin?
Examples of workflow initiation boundaries:
- An SDR can initiate a prospect outreach workflow but not a campaign strategy workflow
- A marketing manager can initiate content drafting and scheduling but not a budget reallocation recommendation
- A finance coordinator can initiate invoice reminder preparation but not system-wide integration changes
Initiation authority is defined by workflow category and can be scoped further by threshold — for example, a team lead can initiate outreach campaigns up to 500 contacts; above that, director or owner approval is required to initiate.
Dimension 3 — Approval authority
Which actions can this role approve for execution?
Approval authority is the most governance-critical dimension. It defines:
- Which action categories this role can approve
- At what scale or threshold their approval is sufficient
- Whether their approval is final or triggers a further step in a multi-level chain
Approval authority is always bounded upward — a role can approve within its threshold but cannot grant itself additional authority. Escalation above threshold is automatic and non-bypassable.
Dimension 4 — Freya interaction mode
How can this role communicate with and direct Freya?
Options include:
- Full natural language: The role can ask Freya any question and instruct any workflow within their scope using conversational input
- Structured query only: The role can submit queries using defined templates or a structured interface — useful for ensuring consistency in how certain roles interact with the system
- Report and dashboard access only: The role cannot initiate queries but receives scheduled outputs and has read access to dashboards
Dimension 5 — Configuration authority
What can this role change about how Freya operates?
Configuration authority is typically restricted to system administrators and senior operational leadership. It governs:
- Ability to modify workflow parameters and agent configurations
- Ability to update approval routing rules and thresholds
- Ability to manage integrations and data connections
- Ability to create, modify, or revoke other user roles (typically system administrators only)
Dimension 6 — Audit and reporting access
What audit records and governance reports can this role access?
This dimension ensures that oversight functions — compliance leads, internal audit, external reviewers, board advisors — have the access they need without that access extending to operational control. It also ensures that operational users cannot access the audit records of colleagues, protecting both privacy and governance integrity.
Section 04
Business / GTM team role example
How role-based control is configured in practice
The table below shows a typical configuration for a growth or go-to-market team using Freya for marketing, sales, and related operations. Your deployment maps to your real titles and thresholds.
| Role | Data scope | Initiation | Approval authority | Audit access |
|---|---|---|---|---|
| CMO | All GTM functions | All GTM workflows | Campaign and budget authority | Full GTM |
| GTM Operations Lead | All GTM functions | Operational workflows | Operational actions | Full GTM |
| Marketing Manager | Marketing function | Marketing workflows | Marketing actions within threshold | Marketing scope |
| SDR Lead | Sales function | Outreach workflows | Outreach actions within volume threshold | Sales scope |
| Agency Client (view) | Client workspace | None | None | Client reporting only |
Section 05
Delegation and temporary access
Governing authority when people are unavailable
Businesses do not pause when key people are on leave, in transition, or temporarily unavailable. Antarious AI role-based control includes structured delegation mechanisms that preserve governance continuity without creating permanent access exceptions.
Formal delegation
An approver with authority can formally delegate their approval role to a named deputy for a specified period. The delegation:
- Requires the delegating authority to specify the deputy, the scope of delegation, and the duration
- Is recorded in the audit trail with full detail
- Automatically expires at the defined end date — no manual revocation required
- Cannot exceed the delegating authority's own permission level (you cannot delegate authority you do not have)
Temporary elevated access
System administrators can grant time-bounded elevated access for specific purposes — for example, an external auditor requiring access during a review period, or a temporary contractor requiring access during a project.
Temporary access:
- Is scoped precisely to the data and actions required
- Has a defined expiry that cannot be extended without a new access grant
- Is fully logged in the audit trail, including the reason for the grant and who authorised it
- Automatically revokes at expiry, with no action required from the administrator
Staff transitions
When a person leaves or changes roles, their access is revoked immediately upon role change in the Antarious AI system. Institutional knowledge is preserved in Freya's memory — it does not leave with the individual. The incoming person in the role can be granted access with their own defined permission profile, which may differ from their predecessor's.
Section 06
What role-based control prevents
The failure modes it is designed to eliminate
Role-based control in Antarious AI is not primarily about restriction — it is about ensuring that every action is taken by someone with the authority, context, and accountability appropriate to that action. The following failure modes are structurally prevented by the role architecture:
Unauthorised workflow initiation
A user cannot instruct Freya to begin a workflow outside their designated scope. Attempts to do so are blocked and logged — not simply declined with an error message.
Approval authority overreach
A user cannot approve an action that exceeds their configured authority threshold. The system automatically escalates to the appropriate higher authority without requiring the original approver to redirect manually.
Data access beyond function
A user cannot access intelligence, dashboards, or records from outside their configured data scope — even if they can see those scopes exist. Data isolation is enforced at the query level, not at the interface level.
Permission self-escalation
No user can modify their own permissions or approve actions on their own behalf. Configuration authority is separated from approval authority by design, and both are separated from audit access.
Permanent access drift
Temporary access arrangements expire automatically. Role configurations are reviewed at configurable intervals and any access that has not been actively confirmed is flagged for administrator review.
Section 07
Governance reporting
Visibility into how authority is being used
Role-based control is not only a preventive mechanism — it is a source of governance intelligence. Freya generates periodic governance reports for system administrators and senior leadership that surface:
- Active roles and permission profiles — a current map of who has what authority in the system
- Approval distribution — which roles are approving what volume and types of actions
- Escalation patterns — which action categories most frequently escalate above initial approval authority, and why
- Delegation log — all active and expired delegations within the review period
- Exception log — all blocked initiation attempts and access boundary encounters
- Dormant access alerts — roles that have not been used within a configured period, flagged for review
These reports are available on demand and can be scheduled for delivery to boards, internal audit, or senior leadership at any frequency.
Section 08
Compliance and framework alignment
References to ISO, GDPR, and similar frameworks describe how role-based controls align with those expectations through internal assessment — not third-party certification unless explicitly stated.
| Framework | Role-based control relevance |
|---|---|
| ISO 27001 — Access Control (Annex A.9) | Role-based access control aligned with least-privilege principle; access provisioning and revocation processes documented |
| UK GDPR / EU GDPR — Data minimisation | Data access scoped to functional necessity; no role has access to data beyond its legitimate operational purpose |
| EU AI Act — Human oversight requirements | Clear authority structures for human oversight of AI outputs; approval authority bounded by role and threshold |
| Sarbanes-Oxley / Internal controls | Separation of duties enforced by role architecture; no individual has unilateral authority over both initiation and approval |
Section 09
Frequently asked questions
How long does it take to configure roles for our organisation during deployment?
Role configuration is completed as part of the onboarding engagement, typically over two to four weeks depending on organisational complexity. Antarious AI's implementation team works with your owners, IT, and operations leads to map your existing authority structures into the system before go-live.
Can we modify roles after deployment?
Yes. Role configurations can be updated by system administrators at any time. All configuration changes are logged in the audit trail, including who made the change, when, and what the previous configuration was.
What happens if someone needs access urgently outside their normal role?
Temporary elevated access can be granted by a system administrator within minutes. The access is scoped, time-bounded, and fully logged. It cannot be self-granted.
Can a user see what permissions they have?
Yes. Users can view a summary of their own permission profile within the platform. They cannot see other users' profiles unless they have administrator access.
How does role-based control interact with our existing SSO or identity management system?
Antarious AI supports integration with enterprise identity providers — including Microsoft Active Directory, Azure AD, Google Workspace, and SAML-compliant providers — so that role assignments can be synchronised with your existing user management infrastructure.
What if our organisation's authority structure is informal or matrix-based rather than hierarchical?
Role-based control in Antarious AI is flexible enough to reflect non-hierarchical authority structures. Matrix approval configurations — where an action requires approval from representatives of two or more functions simultaneously — are fully supported.