Endpoint Controls

Deterministic, policy-enforced controls that define exactly which endpoints/tools are allowed for a given integration. Controls apply at plan time and are hard-enforced at execution.

• Allow-list only: there is no block list. Endpoints are disabled by default until you explicitly enable them.

• Precedence: Deterministic allow-list > Agent Instructions > Intent/Context hints. (The last two are probabilistic guidance.)

What “Enabled” vs “Disabled” means

• Enabled — The planner may include the endpoint; the executor will permit the call.

• Disabled (default) — The endpoint is excluded from plans. If a call is attempted at execution time, it is blocked with a policy error and surfaced in events/SSE.

Deterministic policy is the ground truth. The agent cannot route around it.

Where to configure (UI)

Integration → Integration Endpoints tab:

• Import OpenAPI (.json/.yaml) to populate the table.

• Search path to filter rows (e.g., /PublicHolidays).

• Method filter to narrow the list (All, GET, POST, PUT, DELETE, PATCH, HEAD, OPTIONS).

• Active checkbox per row enables that (method, path) pair.

• Select All to enable everything currently filtered (use sparingly).

• Save to persist. Changes take effect for newly created plans immediately; execution always re-checks policy.

Columns

• Active (checkbox), Path (e.g., /PublicHolidaysByDate), Method (e.g., GET), Source (e.g., api), Description (from spec if available), Updated At (last change/import).

Deterministic vs probabilistic inputs (and why you care)

• Deterministic (hard) — This allow-list. Exact, enforced at both plan and execution.

• Probabilistic (soft)

  • Intent & Context — Hints like “use Pipedrive to schedule…”; helpful, not binding.

  • Agent Instructions — Strong steering (“prefer read-only”; “avoid deletes”), still non-binding.

Deterministic settings win every time. Use them to reduce search space (faster/cheaper) and to prevent unsafe actions.

Operational guidance

• Default-deny naturally: endpoints are off until you turn them on.

• Enable narrowly: only the (method, path) pairs you truly need.

• Writes need scrutiny: for POST/PUT/PATCH/DELETE, enable only what’s required and run with approvalStrategy: ON_TOOL_CALL at run level.

• Spec imports: when you re-import an OpenAPI file, treat it like a deployment. Newly discovered endpoints should remain disabled until reviewed.

• Naming: the identity is (method, path). If GET /reports is enabled, POST /reports is not enabled unless you check it explicitly.

Examples

Open Holidays

• ✅ GET /Countries, GET /Languages, GET /PublicHolidays, GET /PublicHolidaysByDate

• (Leave any POST/PUT/DELETE rows unchecked unless you truly need them.)

Pipedrive (CRM)

• ✅ POST /activities, PUT /deals/{id} (only if required)

• 🔲 DELETE /deals/{id} (keep disabled unless you have a strong, audited use case)

• Run destructive operations with approvalStrategy: ON_TOOL_CALL.

Illustrative configuration (conceptual)

allowed_endpoints:
  - GET /PublicHolidays
  - GET /PublicHolidaysByDate
  - POST /activities
  - PUT /deals/{id}
# there is no deny list; anything not listed remains disabled

Planner & Executor Behavior

• Plan stage - The planner filters candidate tool calls to only those endpoints explicitly enabled in the allow-list. Disabled endpoints are ignored.

• Execution stage - The executor enforces the same allow-list. Only enabled endpoints can be invoked; any attempt to use a disabled one is blocked with a policy error.

Troubleshooting

• “The plan never picks endpoint X.” It isn’t enabled, or the method differs. Enable the exact (method, path) and Save.

• “Run failed with a policy error.” A disabled endpoint was attempted. Check Integration Endpoints and re-enable if appropriate; then start a new run.

• “Planning is slow or scattered.” Tighten the allow-list. Smaller surface → faster, more accurate planning.

Best practices

• Keep your allow-list minimal and explicit.

• Treat changes like deployments (review → stage → roll out).

• For write operations, combine a narrow allow-list with approvalStrategy: ON_TOOL_CALL at run level.

• Use Agent Instructions and Context to guide the model, but rely on the allow-list for guarantees.