Agent Authorization
Control exactly what each agent can access and do — per resource, per action.
Overview
MeetLoyd enforces fine-grained authorization on every tool call. Before an agent can clone a repo, send an email, or update a CRM record, MeetLoyd checks:
Is this agent authorized to perform this action on this resource?
If the answer is no, the action is blocked with an audit trail. No exceptions.
This is powered by OpenFGA — the same Zanzibar-based authorization engine used by Okta and Twitch.
How It Works
Every MCP tool call passes through an authorization check:
- Skill gate — Does the agent have the required skill? (existing)
- Policy gate — Is the agent authorized for this specific resource? (authorization layer)
- Tool execution — Only if both checks pass
Agent calls git_push({ branch: "main" })
↓
Skill check: coding-agent skill? ✅
↓
Policy check: can_push on git_branch:acme/webapp/main? ❌ DENIED
↓
Action blocked. Audit logged.
Resource Types
Authorization covers all connected resources:
| Resource | 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 |
| Committer | Reader + commit, push, create PR |
| Maintainer | Committer + 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:
| Template | What It Grants |
|---|---|
| Read-Only | Read access to all connected resources |
| Contributor | Read + create + update (no delete) |
| Maintainer | Contributor + delete + merge PRs |
| Admin | Full access to all resources |
| CRM Viewer | CRM only: list and read |
| CRM Operator | CRM: list, read, create, update |
| Code Reviewer | Git: clone and read only |
| CI Bot | Git: clone, read, commit, push (feature branches) |
Enforcement Modes
Authorization has three enforcement modes:
| Mode | Behavior |
|---|---|
| Audit | Log all decisions, never block (rollout phase) |
| Warn | Log + alert on deny, but still allow (transition phase) |
| Enforce | Block on deny, full enforcement (production) |
New tenants start in audit mode. Upgrade to enforce when you're confident in your permission setup.
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, etc. Resources are grouped by category (Git, CRM, Drive, Email).
- Pick a template (e.g., "Contributor") — the dropdown automatically shows only templates relevant to the selected resource type
- Click Grant — done
You don't need to know resource IDs or type names. The resource picker shows human-readable names from your connected integrations.
Registering Resources
Click Register Resource in the Resources tab to open the Discover & 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 or click Select all new to pick everything
- Click Register selected to batch-register them
- Use the Manual entry fallback at the bottom for resources not yet covered by auto-discovery
If your integrations aren't showing up, check that they're active in Settings > Integrations. Expired or revoked connections won't 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. Each card shows the resource name, type, and when it was added.
Pending Access Requests
When an agent requests access to a resource it doesn't 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 (repos, CRM objects, folders, etc.) 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 Agent Permissions tab.
Need to register additional resources later? Use the Register Resource button — it re-scans your integrations and shows any resources that haven't been registered yet.
Fail-Closed Design
MeetLoyd's authorization is fail-closed: if the authorization service is unavailable or returns an error, the action is denied. This is an enterprise requirement — an agent being temporarily unable to act is vastly preferable to an unauthorized action.
Audit Trail
Every authorization decision (allow AND deny) is recorded:
- Timestamp — When the check happened
- Agent — Which agent attempted the action
- Action — What was attempted (e.g.,
can_push) - Resource — What resource was targeted (e.g.,
git_branch:acme/webapp/main) - 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
- Streamable to 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), same as Google's internal authorization
- Auto-discovered resources — Resource types and categories are derived from the authorization model, not hardcoded. New resource types appear automatically.
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 this page.
Agent execution starts
↓
Built-in tools (calculator, memory, time, etc.) — always available
↓
OpenFGA grants → derive available tools
↓
Custom tools (tenant-specific) + integration tools (MCP servers)
This means:
- Granting a tool permission on this page immediately makes the tool available to the agent at execution time.
- Revoking a permission immediately removes the tool — no restart needed.
- OpenFGA grants are the sole source of tool assignments. The legacy
toolsfield has been removed.
Delegation Constraints
For admin provisioning tools (Google Workspace Admin, Microsoft 365 Admin), you can set additional constraints on top of authorization:
- Rate limits — per-hour, per-day, and total usage caps
- Domain allowlists — restrict which email domains agents can create users for
- Group allowlists — restrict which groups agents can add members to
- License allowlists — restrict which license SKUs agents can assign
- Approval requirements — require human approval before execution
These constraints work alongside authorization: OpenFGA checks whether the agent can use the tool, constraints control how much and under what conditions.
Integration with Agent Identity
Authorization policies are also enforced during token exchange. When Agent A requests a delegation token to call tools on Agent B, MeetLoyd checks can_execute on each requested tool using the same authorization system described above. An agent can never delegate tools it doesn't have access to.
Next: Learn about Agent Identity for SPIFFE IDs, Badges, SVIDs, and token exchange.