Skip to content

Agentic

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 | Trends

When Agentic-New GAF is enabled, all server-owned MCP execution surfaces converge before the tool is invoked:

Entry surfaceCanonical behavior
JSON-RPC /mcp tools/callRequires an exact Allow and returns a safe MCP error result for Deny, pending approval, or unavailable authorization.
POST /v1/mcp/tool/executeRequires the same decision; responds with 403 Deny, 202 approval required, or 503 unavailable without executing.
Agent Modetools_to_auto_execute is only eligibility; each attempted call still requires Allow.
Code ModeThe 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.

Open Agentic in the workspace sidebar:

PageUse it for
Work QueueReview registrations, high-impact action approvals, drift, and blocked or failed runs.
AssetsRegister or discover agents, tools, named actions, networks, ownership, and risk.
IdentitiesManage users, groups, roles, permissions, service accounts, and identity providers.
MCP ConnectionsManage server connections and the workspace’s MCP configuration in the Settings tab.
Policy & AccessUse Guided access to grant and test least privilege, Action approvals for high-impact actions, and Runtime policy for enforcement.
ActivityUse 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.

  1. 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.

  2. 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_NAME
    NEXT_PUBLIC_AGENTIC_ENTRA_TENANT_ID
    NEXT_PUBLIC_AGENTIC_ENTRA_AUTHORITY
    NEXT_PUBLIC_AGENTIC_ENTRA_GATEWAY_AUDIENCE
    NEXT_PUBLIC_AGENTIC_ENTRA_BLUEPRINT_CLIENT_ID
    NEXT_PUBLIC_AGENTIC_ENTRA_AGENT_IDENTITY_CLIENT_ID
    NEXT_PUBLIC_AGENTIC_ENTRA_JWKS_URI
    NEXT_PUBLIC_AGENTIC_ENTRA_MI_PRINCIPAL_ID
    NEXT_PUBLIC_AGENTIC_ENTRA_SCOPES

    These 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.

  3. 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.

  4. 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.

  5. 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.

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.

VersionRole
static-v2Required deterministic scan. It emits fixed, source-free findings.
model-v2Optional 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.

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.

  1. Deploy the OPA or Cedar decision endpoint.
  2. Allowlist a non-local host with AGENTICNEW_CONTEXT_SIDECAR_ALLOW_HOSTS.
  3. Expand Agentic → Policy & Access → Runtime policy → External context policy.
  4. 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.

OutcomeMeaningNext action
AllowIdentity, resource permission, tool, applicable action, and optional delegation checks passed.The action may run.
DenyAt least one required check failed or the resource is inactive or untrusted.Open Activity → Decisions and correct the missing access or configuration.
Require approvalAccess is otherwise valid, but the action needs human review.Open Work Queue or Policy & Access → Action approvals.

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.

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.