## Core concepts

This page explains the fundamental building blocks of Agen for Work and how they fit together to provide governed AI agent access across your organization.

### AI agents

AI agents are third-party AI assistants — such as ChatGPT, Claude, Copilot, or custom-built agents — that your employees use to automate tasks and interact with business applications. Agen for Work does not host or run these agents. Instead, it acts as a governance layer that sits between AI agents and your organization's SaaS tools, controlling what agents can do and on whose behalf.

When an employee uses an AI agent that attempts to interact with a connected service (for example, creating a Jira issue or reading Google Calendar events), Agen for Work intercepts the request, evaluates it against your policies, and either allows, blocks, or routes it for approval.

### Connectors

Connectors are integrations that link Agen for Work to external SaaS applications. Each connector represents a connection to a specific service — such as GitHub, Slack, Salesforce, Google Drive, or HubSpot — and exposes a set of **tools** that AI agents can invoke.

Adding a connector makes its tools technically available within Agen for Work, but tools are not accessible to users until at least one [policy](#policies) grants access. This separation ensures that enabling a connector does not automatically grant unrestricted access.

Each connector supports two credential modes:

- **Frontegg credentials** — Frontegg manages the OAuth integration on your behalf, requiring no manual credential setup
- **Bring your own** — You provide your own OAuth Client ID, Client Secret, and optional Base URL for custom or self-hosted instances


For more details, see [Connectors](/agen-for-work/sources/overview).

### Tools

Tools are the individual actions exposed by a connector. Each tool maps to a specific API operation within a SaaS application. For example, a GitHub connector might expose tools such as `Get Authenticated User`, `List User Repositories`, `Create Repository`, and `Delete Repository`.

Tools can be toggled on or off at two levels:

- **Connector level** — Enable or disable individual tools when adding or editing a connector
- **Policy level** — Include or exclude specific tools from a policy's scope


This granular control supports the principle of least privilege. You can enable read-only tools broadly while restricting write or delete tools to specific users or requiring approval for their use.

### Policies

Policies are the core access control mechanism. Each policy defines a rule that governs how AI agents interact with your connected SaaS tools — specifying which users or groups can access specific tools within a connector and what enforcement action applies.

Every policy includes:

- **A connector and tools** — Which connector and which specific tools the policy governs
- **An enforcement action** — What happens when an AI agent attempts to use those tools
- **A scope** — Which users or groups the policy applies to (all users, specific users, or specific groups)


#### Enforcement actions

Each policy enforces one of four actions:

| Action | Effect |
|  --- | --- |
| **Allow** | The AI agent can use the tools without restriction |
| **Step up** | The user must re-authenticate before the AI agent can proceed |
| **Deny** | The AI agent is blocked from using the tools entirely |
| **Request approval** | The action is paused until a designated approver grants permission |


When multiple policies apply to the same user and tool combination, the **most restrictive action wins**. The restriction hierarchy from most to least restrictive is: Deny → Request approval → Step up → Allow.

For more details, see [Policies](/agen-for-work/policies/overview).

### Approval flows

Approval flows define the review process for actions governed by **Request approval** policies. Each flow specifies:

- **Notification channels** — How approvers are notified (Email, SMS, or both)
- **Approver chain** — A sequential list of approval steps, each with designated approver groups or individual email addresses
- **Advanced settings** — Auto-approve timeouts, reminders, requester notifications, and CC recipients


When an AI agent triggers a Request approval policy, the action is paused and the request is routed through the assigned approval flow. Approvers review the request and either approve or deny it.

For more details, see [Approval flows](/agen-for-work/approval-flows/overview).

### Users and groups

Users and groups are synced from your identity provider (IdP) and form the basis for policy scoping.

- **Users** represent individual employees in your organization. Each user has a status (Active or Locked) and can be assigned to policies directly.
- **Groups** represent teams or organizational units synced from your IdP (e.g., "Engineering", "Marketing", "Sales"). Groups provide scalable policy assignment — when a user joins or leaves a group in your IdP, their policy assignments update automatically.


Assigning policies to groups rather than individual users is a best practice, as it keeps access in sync with your directory and reduces manual management.

For more details, see [User management](/agen-for-work/access-control/overview).

### Two-layer access control model

Connectors and policies work together to form a two-layer access control model:

1. **Connectors define the tool surface** — By adding a connector and enabling specific tools, you determine which actions are technically available to AI agents
2. **Policies govern access** — Policies then determine which users or groups can use those tools, and what enforcement action applies


Both layers must permit access for an AI agent to successfully invoke a tool. If a connector is disabled, its tools are unavailable regardless of policies. If a connector is enabled but no policy references its tools, those tools remain inaccessible.

### Targeting

Targeting provides conditional rule-based evaluation within a policy. Instead of applying the same enforcement action to every request, targeting lets you define conditions based on contextual attributes — such as the **AI agent type** (e.g., ChatGPT, Claude, Copilot).

Targeting follows an **If / Else** logic structure:

- **If** the targeting rules match (e.g., the agent type is ChatGPT), the policy's configured action applies
- **Else** a default fallback action applies (typically Deny)


This enables scenarios such as allowing a tool only when the request comes from a specific AI agent platform while denying all other agent types.

### Identity provider integration

Agen for Work integrates with your corporate identity provider to sync users and groups. Supported protocols include:

- **SAML** — Okta, Azure AD, Google Workspace, OneLogin, Ping Identity, JumpCloud, Rippling, and custom SAML
- **OpenID Connect** — Okta and custom OpenID
- **SCIM** — For automated user and group provisioning, deprovisioning, and group sync


Connecting an IdP ensures that user lifecycle events (onboarding, offboarding, team changes) are automatically reflected in Agen for Work, keeping AI agent access aligned with your organizational structure.

### Policy evaluation flow

When an AI agent attempts to use a tool on behalf of a user, Agen for Work evaluates the request through the following sequence:

1. **Connector check** — Is the connector enabled and is the specific tool toggled on?
2. **Policy lookup** — Does at least one policy reference this connector and tool for this user?
3. **Targeting evaluation** — If the matching policy has targeting rules, do the conditions match?
4. **Action resolution** — If multiple policies apply, the most restrictive action wins
5. **Enforcement** — The resolved action is applied: Allow, Step up, Deny, or Request approval


If no policy exists for the tool, or if the connector is disabled, the action is blocked by default.

### Key principles

- **Deny by default** — Tools are inaccessible unless explicitly permitted by a connector and a policy
- **Least privilege** — Grant the minimum access required. Use separate policies for read and write tools.
- **Most restrictive wins** — When policies conflict, the most restrictive enforcement action takes precedence
- **Group-based access** — Use IdP groups for scalable, maintainable policy assignments
- **Human-in-the-loop** — Use Request approval policies and approval flows for sensitive or destructive operations