Agentic
Overview
Section titled “Overview”Agentic is the workspace control plane for agent identity, tool and MCP discovery, authorization, approvals, and activity. The normal setup is five steps and uses friendly agent, tool, action, and server names throughout.
Identity proof ↓Agent ↓Authorization: resource + tool + optional action ├─ Allow → Tool or MCP executes ├─ Deny → Blocked └─ Require approval → Held for review ↓Runs | Decisions | TrendsOne canonical MCP execution boundary
Section titled “One canonical MCP execution boundary”When Agentic-New GAF is enabled, all server-owned MCP execution surfaces converge before the tool is invoked:
| Entry surface | Canonical behavior |
|---|---|
JSON-RPC /mcp tools/call | Requires an exact Allow and returns a safe MCP error result for Deny, pending approval, or unavailable authorization. |
POST /v1/mcp/tool/execute | Requires the same decision; responds with 403 Deny, 202 approval required, or 503 unavailable without executing. |
| Agent Mode | tools_to_auto_execute is only eligibility; each attempted call still requires Allow. |
| Code Mode | The outer code meta-call and every nested tool call are authorized separately. |
That decision revalidates the current Virtual Key/agent binding, Registry action, exact-workspace OpenFGA relationships, optional context policy, and Command Authority state. Advisory/shadow configuration, catalogue visibility, an auto-execution list, or an OAuth grant cannot turn a Deny into execution.
MCP OAuth authenticates the gateway’s outbound connection or delegated upstream caller; it does not replace GAF authorization. The legacy direct MCP result cache is also bypassed on canonical calls until a cache key can bind the complete GAF subject, delegated identity, client generation, and decision. See MCP tool execution, MCP OAuth 2.1, and Relationship Authorization.
Navigation
Section titled “Navigation”Open Agentic in the workspace sidebar:
| Page | Use it for |
|---|---|
| Work Queue | Review registrations, high-impact action approvals, drift, and blocked or failed runs. |
| Assets | Register or discover agents, tools, named actions, networks, ownership, and risk. |
| Identities | Manage users, groups, roles, permissions, service accounts, and identity providers. |
| MCP Connections | Manage server connections and the workspace’s MCP configuration in the Settings tab. |
| Policy & Access | Use Guided access to grant and test least privilege, Action approvals for high-impact actions, and Runtime policy for enforcement. |
| Activity | Use Runs, Decisions, and Trends to investigate and monitor Agentic traffic. |
MCP-only users retain MCP Connections when their Agentic access is otherwise limited. Connection inventory and workspace MCP settings remain together; the Settings tab loads only when selected and authorized. Open authorization-safe cache administration from Activity, and advanced relationship/model administration from Policy & Access.
Set up Agentic in five steps
Section titled “Set up Agentic in five steps”-
Review pending work and runtime policy
Open Agentic → Work Queue and triage any registration, action approval, discovery drift, or blocked/failed run. Each row opens the exact review or evidence record. Then open Policy & Access → Runtime policy and confirm the mode is Enforcing. Use Advisory only for a temporary migration or access-change validation.
-
Authenticate people and agents
Open Agentic → Identities → Identity providers. Connect the required Entra identity provider, save it, and test the connection. Add or sync the people, groups, roles, and service accounts that may act through an agent from the other Identities tabs.
Next, open Assets → Agents, select the agent, and choose Identity & credentials. Associate the existing workspace credential and identity provider by name, then save. A provider-backed identity is recommended when separate agent workloads must be distinguished cryptographically.
Deployment builds may optionally prefill a new, disabled Entra provider draft with these public identifiers:
NEXT_PUBLIC_AGENTIC_ENTRA_DISPLAY_NAMENEXT_PUBLIC_AGENTIC_ENTRA_TENANT_IDNEXT_PUBLIC_AGENTIC_ENTRA_AUTHORITYNEXT_PUBLIC_AGENTIC_ENTRA_GATEWAY_AUDIENCENEXT_PUBLIC_AGENTIC_ENTRA_BLUEPRINT_CLIENT_IDNEXT_PUBLIC_AGENTIC_ENTRA_AGENT_IDENTITY_CLIENT_IDNEXT_PUBLIC_AGENTIC_ENTRA_JWKS_URINEXT_PUBLIC_AGENTIC_ENTRA_MI_PRINCIPAL_IDNEXT_PUBLIC_AGENTIC_ENTRA_SCOPESThese values are compiled into downloadable browser JavaScript. They never override a provider saved in the active workspace and must never contain a client secret, token, certificate, private key, password, connection string, or secret reference. Shared multi-tenant SaaS builds should leave all nine unset and configure providers independently in each workspace.
-
Discover agents, tools, actions, and MCP
For each MCP server, open Agentic → MCP Connections, choose its transport and authentication method, and create the live connection. Use Settings on that page for workspace MCP configuration. Then compile or run the discovery-enabled agent workflow once.
Confirm the live connection and friendly tool names in MCP Connections. In Assets, confirm the workflow-discovered agent, tools, named actions, and MCP inventory have the expected names, status, and risk. Review unexpected tools before granting access.
-
Grant and prove least privilege
Open Agentic → Policy & Access → Guided access. Select:
- the agent and, when applicable, the person or service account it acts for;
- the target resource and required permission;
- the tool; and
- the exact named action, when the tool exposes one.
Add a time-limited delegated scope only when the agent acts on behalf of another identity. Click Grant access, then Check access and review every result before running production traffic.
High-impact actions are held in Work Queue and Policy & Access → Action approvals. Review the agent, actor, tool, action, and target, then approve or deny. An approval cannot override a hard denial.
-
Run and observe
Route the agent and MCP traffic through the DeepIntShield gateway, then open Agentic → Activity:
- Runs shows one workflow and its agents, tools, actions, and outcome.
- Decisions explains each Allow, Deny, or Require-approval result.
- Trends summarizes volumes, outcomes, top agents and tools, and latency.
Use Activity → Trends for activity and outcome graphs and select Secure caches from Activity for authorized cache savings. Langfuse/OpenTelemetry export is managed by the backend deployment and is not a workspace form. Export failure never changes or removes the local authorization record.
Blueprint code review
Section titled “Blueprint code review”Supported framework execution binds registration to implementation evidence,
not just an agent or tool name. Native discovery sends a bounded,
credential-redacted source bundle and a mandatory coverage ledger for every
declared local executable. Missing, partial, truncated, or omitted coverage
fails closed as blueprint_coverage_incomplete; a scanned prefix is never
treated as safe.
A remote MCP tool is exempt from local source capture only when the server matches its selector to a configured MCP connection in the authenticated workspace. Adding an arbitrary remote-server label to a discovery report does not create an exemption.
| Version | Role |
|---|---|
static-v2 | Required deterministic scan. It emits fixed, source-free findings. |
model-v2 | Optional additive model prompt/schema. It cannot erase static findings, declare code safe, or approve a blueprint. |
Configure optional model analysis under Policy & Access → Runtime policy → Blueprint protection. The protected Virtual Key picker searches the active workspace with bounded, server-paged requests, can reach keys beyond the first 200 rows, and offers only models allowed by the selected active key. It retains an exact configured key outside the current page, accepts organization-wide keys, rejects sibling-workspace keys, never returns the key secret, and keeps Save locked when key state cannot be verified.
A code digest, static-v2/model-v2 version, policy generation, or protected
key/model routing change requires fresh attestation and review. New or changed
code waits for one bounded synchronous scan acknowledgement. Unchanged approved
code avoids repeated scanner/model calls, but normal authorization and network
latency still apply and must be measured for the deployment.
Static and model findings are bounded risk signals, not perfect detection or proof of safe code. Keep signed builds, repository review, dependency controls, sandboxing, egress policy, and gateway authorization in place.
The SDK renders stable machine codes rather than remediation prose. Common
codes include agent_registration_pending, blueprint_coverage_incomplete,
blueprint_scan_unavailable, require_approval, and guardrail_denied.
Work Queue, blueprint/registration review, action approvals, and
Activity → Decisions own the human explanation and next action.
See Agents and Agentic governance for the Python enforcement surface and SDK error codes for every stable code, trusted description, retry hint, operator action, and dashboard path.
Optional external context policy
Section titled “Optional external context policy”Normal relationship authorization does not require this integration. Use it only for OPA or Cedar attribute rules such as risk, time, location, or data sensitivity:
- OPA (Open Policy Agent) applies Rego policies to flexible JSON input.
- Cedar applies permit/forbid policies to a structured principal, action, resource, and context request.
DeepIntShield runs identity, delegation, permission, tool, and action checks first. If they pass, it sends the relevant runtime attributes to the configured engine. The request is allowed only when both the relationship checks and the external context decision allow it.
- Deploy the OPA or Cedar decision endpoint.
- Allowlist a non-local host with
AGENTICNEW_CONTEXT_SIDECAR_ALLOW_HOSTS. - Expand Agentic → Policy & Access → Runtime policy → External context policy.
- Select the engine, enter the complete decision URL, and select Save & enable.
The URL field reports missing, invalid, and server-rejected values. Evaluation is fail-closed, so leave the integration off when no external policy service is deployed.
Expected outcomes
Section titled “Expected outcomes”| Outcome | Meaning | Next action |
|---|---|---|
| Allow | Identity, resource permission, tool, applicable action, and optional delegation checks passed. | The action may run. |
| Deny | At least one required check failed or the resource is inactive or untrusted. | Open Activity → Decisions and correct the missing access or configuration. |
| Require approval | Access is otherwise valid, but the action needs human review. | Open Work Queue or Policy & Access → Action approvals. |
Friendly names and signed evidence
Section titled “Friendly names and signed evidence”The everyday UI shows display names for agents, identities, tools, actions, servers, runs, and decisions. Activity pages summarize evidence integrity as a status instead of exposing internal identifiers or cryptographic values.
Signed inventory exports from Assets may include canonical identifiers and cryptographic proof for audit verification. Those values are audit evidence, not fields users need to copy into normal Agentic forms.
Advanced configuration
Section titled “Advanced configuration”From Policy & Access, open Advanced relationships only when you need to:
- edit and publish the OpenFGA authorization model;
- manage raw relationships or model assertions;
- inspect model and relationship changes; or
- run low-level authorization diagnostics.
Treat model and relationship changes like code: test positive and negative assertions, review the change, publish it, and verify access again.
Next steps
Section titled “Next steps”- Relationship Authorization — advanced role, resource, action, and delegated-access modeling.
- Agentic Observability — investigate runs, decisions, trends, and optional telemetry export.
- Connect MCP servers — transports, authentication, health checks, and tool discovery.
- MCP tool execution — run an authorized MCP tool through the gateway.
- Virtual keys — create and manage workspace credentials.
- Python SDK Agentic governance — enforce decisions at supported framework and tool boundaries.