Agent Authorization
Agent authorization controls exactly what each agent can access and do — per resource, per action. Powered by OpenFGA (the same Zanzibar-based authorization engine used by Okta and Twitch), it ensures that no agent can clone a repo, send an email, or update a CRM record unless explicitly permitted.
This guide covers how authorization works, how to grant and manage permissions, and the security principles that underpin the system.
How It Works
Every MCP tool call passes through a two-step authorization check before execution:
- Skill gate — Does the agent have the required skill assigned?
- Policy gate — Is the agent authorized for this specific resource?
Only if both checks pass does the tool execute. If either fails, the action is blocked and an audit entry is created.
Resource Types
Authorization covers all connected resources:
| Resource Type | Example Permissions |
|---|---|
| Git Repositories | Clone, read, commit, push, create PR, merge PR |
| Git Branches | Push, merge (branch-level control) |
| CRM Objects | List, read, create, update, delete, export |
| Drive Folders/Files | Read, write, delete, share |
| Email Domains | Send, read, delete |
| Email Addresses | Send as, read |
| Integrations | Read, write, execute, configure |
Roles
Permissions are derived from roles. Assign a role once and the agent gets all associated permissions.
Git Roles
| Role | Permissions |
|---|---|
| Reader | Clone, read |
| Writer | Reader + commit, push, create PR |
| Maintainer | Writer + merge PR |
| Admin | Maintainer + manage settings |
CRM Roles
| Role | Permissions |
|---|---|
| Viewer | List, read |
| Editor | Viewer + create, update |
| Admin | Editor + delete, export |
Drive Roles
| Role | Permissions |
|---|---|
| Viewer | Read |
| Editor | Viewer + write |
| Admin | Editor + delete, share |
Permission Templates
Apply common permission patterns with one click. Templates are per-category — granting a Git template never writes CRM tuples and vice versa.
| Category | Templates |
|---|---|
| Git | Code Reader, Code Writer, Code Maintainer, Code Admin |
| CRM | CRM Viewer, CRM Editor, CRM Admin |
| Drive | Drive Viewer, Drive Editor, Drive Admin |
| Email Reader, Email Sender, Email Admin | |
| Integration | Integration Reader, Integration Editor, Integration Admin |
Enforcement Modes
| Mode | Behavior |
|---|---|
| Progressive | When an agent needs a permission it lacks, it raises an approval request and waits — you grant the exact, minimal access in a click. Approved grants accumulate as you work. (default for new workspaces) |
| Audit | Log all decisions, never block (rollout phase) |
| Warn | Log and alert on deny, but still allow (transition phase) |
| Enforce | Block on deny, full enforcement (production) |
New workspaces start in progressive mode, so the right permissions build up naturally as your agents work — which means you can later switch to enforce with no disruption, because everything legitimate has already been approved. See Permissions & trust for the why.
If the permission service is ever unavailable, MeetLoyd fails closed — it denies rather than letting actions through unchecked. An outage locks things down; it never accidentally opens them.
Enterprise tenants with compliance packs (HIPAA, SOX, DORA) are automatically set to enforce mode.
Granting Access
The Authorization page has a Grant Access bar at the top — always visible, works for every resource type.
- Pick an agent from the dropdown
- Search for a resource — type a name and MeetLoyd searches across all your connected repos, CRM objects, folders, and more. Resources are grouped by category.
- Pick a template (e.g., "Contributor") — the dropdown automatically shows only templates relevant to the selected resource type
- Click Grant — done
You do not need to know resource IDs or type names. The resource picker shows human-readable names from your connected integrations.
Cascading Grants
The Grant Access bar supports three subject levels via an Agent / Team / Workspace toggle:
| Level | Scope | Use Case |
|---|---|---|
| Agent | Single agent only | Specific access for one agent (e.g., coding agent with repo write) |
| Team | All agents in that team (including future additions) | Shared tooling for a group (e.g., Sales team with CRM editor) |
| Workspace | All teams and agents in that workspace | Broad policies across all teams (e.g., all agents with Drive read) |
Grants cascade downward: a workspace grant applies to all teams in the workspace, and each team grant applies to all agents in the team. The Agent Detail view in the Permissions tab shows the source of each grant ("Granted Via" indicator), so you can trace whether a permission comes from the agent directly, its team, or its workspace.
Start with workspace-level grants for common resources (Drive, email), then use team-level for department-specific tools (CRM for Sales, Git for Engineering), and agent-level for exceptions.
Registering Resources
Click Register Resource in the Resources tab to open the Discover and Register dialog. MeetLoyd automatically scans your connected integrations and lists available resources:
- GitHub — your organizations and repositories
- HubSpot — CRM object types (contacts, companies, deals, tickets) and pipelines
- Google Workspace — Gmail and Drive access
Resources are grouped by integration. Already-registered resources are marked with a "Registered" chip. You can select individual resources, batch-register them, or use the manual entry fallback for resources not yet covered by auto-discovery.
If your integrations are not showing up, check that they are active in Settings > Integrations. Expired or revoked connections do not appear in discovery.
Browsing Resources
The Resources tab shows all registered resources as cards, grouped by category (Git, CRM, Drive, Email, etc.). Use the filter chips at the top to narrow by category.
Pending Access Requests
When an agent requests access to a resource it does not have permission for, a pending request banner appears at the top of the page. Click it to open the review drawer where you can approve or deny each request.
Default Permissions
When you connect a new integration, MeetLoyd automatically:
- Discovers available resources via connector screening
- Registers them in the authorization system
- Grants default read-only access to relevant agents
You can then upgrade permissions via the Grant Access bar or the Permissions tab.
Tool Resolution at Execution Time
When an agent runs, MeetLoyd determines which tools are available based on OpenFGA grants — the same permissions you manage on the Authorization page.
Built-in tools (calculator, memory, time, etc.) are always available. Integration and custom tools are derived from OpenFGA grants. Granting a tool permission immediately makes it available; revoking a permission immediately removes the tool. No restart needed.
Delegation Constraints
For admin provisioning tools (Google Workspace Admin, Microsoft 365 Admin), you can set additional constraints on top of authorization:
| Constraint | What It Controls |
|---|---|
| Rate limits | Per-hour, per-day, and total usage caps |
| Domain allowlists | Which email domains agents can create users for |
| Group allowlists | Which groups agents can add members to |
| License allowlists | Which license SKUs agents can assign |
| Approval requirements | Human approval required before execution |
These constraints work alongside authorization: OpenFGA checks whether the agent can use the tool, constraints control how much and under what conditions.
Loyd Authorization
Loyd, MeetLoyd's built-in AI assistant, is governed by the same authorization system as every other agent. When Loyd is created or synced, the platform automatically provisions 15 OpenFGA resource grants covering all of Loyd's tools.
This means full transparency (see exactly what Loyd can access in the Permissions tab), full control (revoke or downgrade any grant), and full audit (every Loyd tool call is logged). Loyd's permissions are additionally constrained by a code-level allowlist as defense-in-depth.
If your organization requires strict control over system agents, switch to enforce mode and review Loyd's grants in the Permissions tab under Agent Detail.
Fail-Closed Design
MeetLoyd's authorization is fail-closed: if the authorization service is unavailable or returns an error, the action is denied. An agent being temporarily unable to act is vastly preferable to an unauthorized action.
Audit Trail
Every authorization decision (allow and deny) is recorded with:
| Field | Description |
|---|---|
| Timestamp | When the check happened |
| Agent | Which agent attempted the action |
| Action | What was attempted (e.g., push, merge, send) |
| Resource | What resource was targeted |
| Tool | Which MCP tool triggered the check |
| Result | Allowed or denied |
| Duration | How long the check took |
Denied decisions are also logged to the team activity feed, included in watchdog alerts, and streamable to your SIEM (if enabled).
Security Principles
- Default deny — if no permission is explicitly granted, the action is blocked
- Fail closed — if the authorization check fails, the action is denied
- Least privilege — default permissions are read-only; upgrade as needed
- Full audit — every decision is logged, no exceptions
- Enterprise-grade — powered by OpenFGA (Zanzibar model)
- Auto-discovered resources — resource types and categories are derived from the authorization model, not hardcoded
Integration with Agent Identity
Authorization policies are also enforced during token exchange delegation. When Agent A requests a delegation token to call tools on Agent B, MeetLoyd checks permissions using the same authorization system. An agent can never delegate tools it does not have access to.
Next: Learn about Agent Identity for SPIFFE IDs, Badges, SVIDs, and token exchange.