Agentic Security

Overview

Agentic Security turns DeepIntShield into a policy enforcement and decision control plane for your AI agents. Every tool call an agent makes is authorized before it runs, returning one of four verdicts - Allow, Deny, Require approval, or Mask - along with any obligations (such as PII masking) the caller must apply. The decision happens inline on the gateway hot path, so you get tool-call authorization without standing up a separate sidecar or adding a network round-trip to your agents.

Beyond simple name-based allow-lists, the Tool Integrity Engine inspects what each call actually does - its arguments and, for code-mode tools, its source - and compares that to the tool’s declared contract. It catches an “approved” tool that suddenly behaves wrong (parameter pollution, command injection, a read tool that starts writing or reaching the network) and can flag, escalate, or block the divergence. Paired with tool pinning, behavior-fingerprint-bound approval grants, and an exportable AIBOM (AI Bill of Materials), it gives you runtime supply-chain assurance over your entire agentic tool surface.

Every decision is written to a tamper-evident, hash-chained audit trail that stores only argument digests - never raw arguments - so you keep a provable record with zero data egress.

Key benefits

• Inline tool-call authorization - four-verdict decisions (Allow / Deny / Require approval / Mask) on the hot path, with cached verdicts returning in microseconds.
• Behavior integrity, not just names - detect “in-scope but wrong” tool calls, action-class escalation, and injection signatures the moment they occur.
• Safe rollout - run new controls in Shadow to measure exactly what they would have blocked before you flip to Enforce.
• Human-in-the-loop approvals - high-risk actions queue for a reviewer, who can approve once, for a session, or always - bound to the tool’s exact behavior.
• Tamper-evident audit + AIBOM - a hash-chained decision log and a signed CycloneDX-flavored inventory of your tools, ready as compliance evidence.
• Standards-mapped - decisions are auto-tagged to the OWASP Agentic Top 10, with cross-walks to NIST AI RMF, ISO 42001, the EU AI Act, and MITRE ATLAS.

Plan availability

The core PEP/PDP - tool-call decisions, the four-verdict model, the visual policy builder, per-tool tiering, the permission-template gallery, and the hash-chained decision audit - is available on Team and above. The advanced controls - the Tool Integrity Engine, tool pinning + AIBOM, behavior-bound approval grants, agent identity providers / registry, and Shadow / Canary / Enforce rollout - require Business or above (Business, Enterprise, and Enterprise VPC).

When to use it

Reach for Agentic Security when:

• You run autonomous or semi-autonomous agents (via the SDK, MCP servers, or a framework like LangGraph or CrewAI) that call tools, and you need to govern which actions execute, not just which prompts are sent.
• You want a human gate on high-recovery-cost actions (writes, payments, deletes, data egress) without blocking the agent’s safe work.
• You need to detect tool tampering, descriptor injection, typosquatting, or re-described MCP tools at runtime.
• You must produce auditable, standards-mapped evidence of every agent action for security review or compliance.
• You are rolling out new agentic controls and want to measure their blast radius before enforcing them.

How decisions work

Each tool call is evaluated against your published policies and the calling agent’s attributes, then combined with the tool’s sensitivity tier and integrity posture to produce a verdict:

Verdict	Meaning	Typical use
Allow	The call proceeds unchanged.	Safe, in-contract reads and low-risk actions.
Mask	The call proceeds, but the caller must apply obligations (e.g. redact PII in arguments) first.	Tools that may receive sensitive arguments.
Require approval	The call is held and queued for a human reviewer.	High-recovery-cost actions, or a behavior divergence on a sensitive tool.
Deny	The call is blocked and never executes.	Disallowed actions, cross-tenant delegation, or a hard integrity violation.

Decisions are closed by default: a high-sensitivity tool fails closed (denied) if no policy can be evaluated for it.

Agent-prompt guardrail

When your agent passes its current instruction to a decision (prompt=…), the gateway runs it through an in-process injection / PII guardrail at the decision boundary - the same signatures the integrity engine uses, with no extra network hop. A hit is tagged OWASP “Goal hijacking”, raises the decision’s risk, and is exposed to policy as the prompt_injection / prompt_pii operands so you can gate on it (for example, require approval when prompt_injection). The raw prompt is scanned then discarded - never stored (zero-data-retention) - and the signal is part of the decision cache key, so a flagged prompt can never be served a cached clean verdict while a clean prompt is byte-identical to no prompt (no added latency on the common path).

This complements the content guardrails that already scan the prompt on the LLM surface: AI Guardrails govern the prompt; Agentic Security governs the resulting tool action.

Risk score

Every decision carries a composite risk score (0–100, with a low / medium / high / critical band) blended from the verdict severity, integrity / prompt risk, OWASP weight, tool sensitivity, recovery cost, and cross-tenant status. It is computed off the decision hot path and surfaced per step in the execution view, per agent on the identity card, and aggregated on the Posture dashboard - so “how risky was this run / agent / tool?” is one number, consistent everywhere.

Configuration

All Agentic Security configuration lives in the Workspace → Agentic Security area of the web console - it is managed per workspace and tenant in the control plane through the Web UI, not through any local file. Agents call the decision engine through the DeepIntShield Python SDK, which builds the request for you. The sections below show the console workflow and the SDK usage.

1. Tier your tools

Open Agentic Security → Tools & Sensitivity Tiering. Each tool you register carries a sensitivity tier that drives how much enforcement it gets.

Web UI

1. Go to Tools & Sensitivity Tiering. The Installed tab shows your tiered tools; the Catalog tab offers pre-classified starters you can adopt in one click.

2. Add or edit a tool and set:

   • Sensitivity - low, medium, or high.
   • Fail posture - what happens when policy can’t be evaluated (high-risk tools should fail closed).
   • Revocation - the revocation path for cached approvals on this tool.
   • Obligations - e.g. mask:pii, unioned with any policy obligations and applied before the tool runs.

3. Use the Enforce switch on each row to put a tool in enforce or shadow mode.

4. (Business+) In the Supply chain column, click Pin to anchor the tool to its current contract fingerprint. Any later change to the tool’s contract trips drift detection at decision time.

SDK

Reference a tool by the same name you registered on the Tools & Sensitivity Tiering page when you gate it in code:

from deepintshield import DeepintShield

shield = DeepintShield(virtual_key="sk-bf-…", base_url="https://app.deepintshield.com")

# The tool name must match the entry on the Tools & Tiering page.
@shield.agentic.tool("db.write", recovery_cost="high")
def write_ledger(row: dict) -> dict:
    return db.execute(...)

The recovery_cost hint (low / medium / high) feeds the autonomy budget, so high-cost actions are more likely to require approval.

2. Author policies

Open Agentic Security → Policies - Rule Builder. The visual builder is the source of truth; on publish it compiles your rules and applies them to the affected workspace.

1. On the Builder & Rules tab, click Configure on a rule (or adopt a starter from the Catalog tab) to open the editor.

2. Set the rule’s verdict (Allow / Deny / Require approval / Mask) and its conditions. Policies can match on attributes such as the effective action class, integrity risk, behavior divergence, fingerprint drift, code threat (malicious tool source - T11/T17), prompt injection, prompt PII, agent risk level, agent capability, namespace, relationship (OpenFGA/ReBAC), memory integrity (T1), hallucination risk (T5), goal drift (T7), approval pressure (decision-fatigue throttle - T10), comm integrity (T12), delegation depth (T14), output manipulation (manipulated agent response - T15), RAG provenance, recovery cost, cross-tenant status, identity type, scope, data class, and time of day.

3. Set the rule’s scope: apply to all keys, or target specific virtual keys, teams, or members.

   Per-object relationships

   The relationship operand authorizes the specific object a tool call targets (ownership, group/team membership, folder→document inheritance) via the OpenFGA/ReBAC backend. Grant per-tool permissions, inspect tuples, and check access paths in the interactive ReBAC Studio (Agentic Security → ReBAC Studio).

4. Save as a draft, then Stage and Publish. Publishing bumps the policy version and invalidates cached decisions for the affected workspace, so changes take effect on the next call.

Start from a template

The Catalog tabs ship one-click permission templates mapped to OWASP Agentic categories - including Read-Only Discovery, Developer Prototype, Production Strict, Finance Write (Human-in-the-loop), Data Egress Controlled, RAG-Only Knowledge Agent, and Incident-Response Break-Glass - plus a rule pack per OWASP Agentic Top 10 category (ASI01–ASI10) and a gap-operand pack (Block Malicious Tool Code, Block Poisoned Memory, Gate High-Hallucination Actions, Block Goal Drift, Throttle Approval Flood, Block Unauthenticated Inter-Agent Messages, Cap Delegation Depth, Block Manipulated Output). Adopt one to get a hardened posture without authoring rules from scratch.

3. Roll out enforcement safely

Open Agentic Security → Rollout & Enforcement Control to choose how verdicts are applied for the workspace.

Mode	Behavior
Shadow	Verdicts are computed and logged but never block. The divergence report shows what would have been denied or escalated.
Canary	Enforces for this workspace only, so you can watch the verdict distribution and false-positive rate.
Enforce	Full enforcement - cached verdicts return in microseconds, misses in sub-millisecond p99.

Additional controls on this page:

• Kill switch - instantly disables all enforcement for the workspace, with no redeploy.
• Tiers enforced - promote enforcement tier by tier (low → medium → high) as divergence becomes acceptable.
• Revocation SLA (s) - bounds how long a cached Allow can live, so a verdict never outlives the promised revocation window.
• Fail closed by default - when on, unconfigured high-risk calls are denied rather than allowed.

The divergence tiles (Would-deny if enforced, Would-escalate, Would-allow, Unexpected denies) let you measure a policy’s blast radius before you flip it to Enforce.

4. Connect agent identities (Business+)

Open Agentic Security → Agents & Identity to plug agents into your existing identity provider. The broker accepts agent tokens natively and normalizes them into a single delegation context - the policy layer only ever sees the normalized context, never the raw token.

1. On the Providers tab, add a provider: Microsoft Entra Agent ID, ZeroID (RFC 8693), or Generic OIDC / OAuth 2.1.

2. For Entra, use the Connect Entra wizard to set the Directory (tenant) ID, Blueprint (client) ID, Token audience, and Blueprint credential (Managed Identity FIC is recommended). Click Test connection to verify and view the detected claims.

3. On the Claim Mapping tab, map provider claims to delegation-context fields (principal, actor chain, identity type, tenant, scope). Cross-tenant status is computed automatically, and cross-tenant delegation is denied before any policy runs.

4. On the Agent Registry tab, record each agent identity with an accountable owner, owning team, version, and purpose for traceability.

5. Gate tool calls from your agents (SDK)

The Python SDK enforces verdicts wherever your agents run. Identity and policy machinery is auto-discovered from the gateway - you supply only your virtual key and gateway URL.

The recommended path is automatic: the moment you construct DeepintShield(...), the SDK installs enforcement guards for every agent framework you’ve imported (LangGraph, CrewAI, LlamaIndex, AutoGen, PydanticAI, the OpenAI Agents SDK, LiteLLM). Compiling/building an agent then yields an already-governed object - you can’t forget to gate it, and you can’t bypass it by invoking the un-governed one.

Automatic (recommended)

from langgraph.graph import StateGraph, START, END
from deepintshield import DeepintShield, GuardrailDenied

shield = DeepintShield(virtual_key="sk-bf-…", base_url="https://app.deepintshield.com")

def crm_read(s): ...          # your plain tools/nodes, unchanged
def admin_grant(s): ...

g = StateGraph(State)
g.add_node("read_step", crm_read)
g.add_node("admin_step", admin_grant)
...
app = g.compile()             # auto-governed - every node is now gated by the PDP
app.invoke({...})             # a DENY raises GuardrailDenied before the node runs

Security follows the implementation, not the label: each node/tool is governed by its function name (crm_read), not the node label (read_step), and the decision is bound to a fingerprint of the function’s source. (Import a framework after building the client? Call shield.agentic.enforce() once.) These client guards are cooperative defense-in-depth - the gateway (MCP/LLM in the call path) stays the authoritative boundary.

govern() - register + scan

govern() makes it explicit and adds blueprint registration + source-code threat scanning (T11 RCE / T17 supply chain, server-side, ZDR). Idempotent, so it’s safe alongside the automatic guard:

app = shield.agentic.govern(app)

The server scans each declared tool’s source for malicious code (remote execution, shell-out, unsafe deserialization, secret exfiltration). A flagged tool surfaces under Agentic → Findings and - when the workspace enables Enforce code threat (Rollout) - is denied even if a policy would allow it. Choose the scan model per workspace (a virtual key) on the Rollout page. A tool called but never declared shows up as ASI04 drift under Agentic → Discovery.

Decorator / binders

@shield.agentic.tool("db.write", recovery_cost="high")
def write_ledger(row: dict) -> dict:
    return db.execute(...)

# or instrument a framework object in place:
shield.agentic.govern(compiled_graph)   # auto-detects LangGraph / CrewAI / LlamaIndex /
shield.agentic.govern(tools)            # AutoGen / PydanticAI / OpenAI Agents

# Verdicts map to Python outcomes automatically:
#   Allow → body runs · Mask → kwargs redacted · Require approval → waits for a reviewer · Deny → raises GuardrailDenied

Direct probe

Call the decision engine directly to get the raw verdict without raising (useful for tests or custom flows):

decision = shield.agentic.decide(
    tool="db.write",
    args={"table": "ledger", "op": "insert"},
    recovery_cost="high",
    prompt=user_instruction,   # optional: scanned by the prompt guardrail, then discarded (ZDR)
)
print(decision.verdict)        # ALLOW / DENY / REQUIRE_APPROVAL / MASK
print(decision.obligations)    # e.g. ["mask:pii"]

The SDK is the recommended path because it builds the decision request and applies verdict obligations for you.

Tool Integrity Engine & supply-chain assurance (Business+)

The Tool Integrity Engine runs inline on the decision path, before policy. It compares each call’s observed behavior against the tool’s declared contract and produces a deterministic integrity signal with named flags - with no LLM and no third-party call.

What it catches:

• Behavior divergence - an allowed tool whose actual arguments or source don’t match its declared action class or argument schema.
• Action-class escalation - a tool classified read that suddenly writes, shells out, reaches the network, or deletes.
• Injection signatures - SQL injection, shell metacharacters, path traversal, and prompt-injection patterns riding inside tool arguments.
• Schema conformance - undeclared, smuggled, or unexpected parameters that signal tampering.
• Fingerprint drift - a pinned tool whose contract changed since pinning (descriptor injection, typosquatting, re-described MCP tools), caught at decision time.

Source-code threat scanning (T11 RCE / T17 supply chain)

When an agent registers its blueprint (via govern() or the automatic compile guard), each declared tool’s source is scanned once for malicious code - remote execution (eval/exec/os.system/subprocess), unsafe deserialization (pickle), remote fetch-and-run, destructive filesystem ops, and secret/credential exfiltration. The verdict is bound to the tool’s source fingerprint and cached, so it costs nothing on the decision hot path, and the raw source is never stored (zero-data-retention) - only the verdict.

Scanning is configured per workspace on the Rollout page:

• Scan mode - Off, Signatures (fast, deterministic, in-process), or Signatures + model (also classifies through a virtual key you select, falling back to signatures if the model is unavailable).
• Enforce code threat - when on, a tool whose source scans malicious is denied even if a policy would allow it (honours the shadow → canary → enforce rollout). The finding is tagged Supply chain and inherits the NIST AI RMF / ISO 42001 / EU AI Act / MITRE ATLAS crosswalk.

Adopt the Block Malicious Tool Code template (Catalog) to turn this into a one-click policy.

Per-tool integrity posture

Each tool carries an integrity posture that maps a diverged signal to a verdict:

Posture	Effect
Flag	Record the divergence only; the call proceeds.
Approval	Route the diverging call to the human-in-the-loop queue.
Block	Hard-deny the call.

You can also write policy on these signals directly - for example, Deny when integrity risk is high or Require approval when fingerprint drift is true - using the integrity operands in the rule builder.

Behavior-bound approval grants

When a reviewer approves a held call, they can persist the decision as a grant bound to the caller plus the tool’s exact behavior fingerprint:

• Session - auto-allows the same tool and logic for the session (time-boxed).
• Always - auto-allows persistently until revoked or the tool’s behavior changes.

A grant can only upgrade a Require approval to Allow - it never overrides a Deny, and it auto-expires the instant the tool’s action class, argument schema, or source changes. Manage active grants on the Approvals → Grants tab, where you can Revoke any grant immediately.

Export an AIBOM

On the Tools & Sensitivity Tiering page, click Export AIBOM to download a CycloneDX-flavored AI Bill of Materials for the workspace’s tool surface. The export includes, per tool, its action class, sensitivity, argument schema, live contract fingerprint, pin attestation (who pinned it and when), and drift status - plus a sha256 attestation digest and counts of pinned and drifted tools.

The AIBOM is cryptographically signed: a signature block carries an Ed25519 signature over the attestation digest, the signing public key, and a stable key id. Because it’s asymmetric, any auditor can verify the AIBOM wasn’t tampered with - ed25519.Verify(public_key, digest, value) - without a shared secret. This is the verifiable SBOM the OWASP Agentic T17 (Supply Chain) mitigation calls for. The signing key is derived deterministically from DEEPINTSHIELD_AIBOM_SIGNING_SEED (set it in production so the public key is stable and externally pinnable).

Approvals & audit

• Approvals - Human in the Loop (Agentic Security → Approvals): the Pending queue lists held calls with the full delegation chain, tool, recovery cost, and any integrity divergence. Open a request to review the decision detail and a plain-language summary of what the tool does, then Approve, approve for Session, approve Always, or Deny. Arguments are shown by digest only.
• Overview & audit trail (Agentic Security → Overview): KPI tiles (decisions, allow rate, deny rate, pending approvals, bypass events), the verdict-distribution bar, and the full hash-chained decision trail filterable by verdict, tool, OWASP category, and identity. Click Export evidence to download the filtered set as CSV, including each row’s hash and previous hash for tamper-evidence.
• Agentic Logs (Workspace → Agentic Logs): the standard logs view scoped to agent and tool decisions, for line-by-line investigation.

Zero data retention

The audit trail stores only sha256 argument digests, never raw arguments. Integrity analysis scans raw arguments in memory only and never persists them, so you keep a full forensic trail without retaining sensitive payloads.

Field & option reference

Setting	Where	Values / notes
Sensitivity	Tools & Tiering	low · medium · high
Fail posture	Tools & Tiering	Per-tool behavior when policy can’t be evaluated
Obligations	Tools & Tiering	e.g. mask:pii; unioned with policy obligations
Enforce	Tools & Tiering	Per-tool enforce vs shadow toggle
Pin / Unpin	Tools & Tiering (Business+)	Anchor a tool to its contract fingerprint
Verdict	Policies	Allow · Deny · Require approval · Mask
Scope	Policies	All keys, or target virtual keys / teams / members
Status	Policies	draft → staged → published (or archived)
Mode	Rollout	Shadow · Canary · Enforce
Kill switch	Rollout	Instantly disables enforcement, no redeploy
Tiers enforced	Rollout	Promote low → medium → high
Revocation SLA (s)	Rollout	Bounds cached-Allow lifetime
Fail closed by default	Rollout	Deny unconfigured high-risk calls
Provider type	Agents & Identity (Business+)	Entra Agent ID · ZeroID · Generic OIDC
Integrity posture	Tools / Policies (Business+)	Flag · Approval · Block
Grant scope	Approvals (Business+)	Once · Session · Always

Examples

Hard-block a destructive tool unless it behaves exactly as declared. Tier db.delete as high sensitivity with fail closed, set its integrity posture to Block, and Pin it. Publish a policy that denies the tool by default and a separate rule that requires approval for any drift. A call that name-checks clean but escalates its action class is blocked; a contract change trips drift on the next call.

Gate finance writes behind a human, then remember the approval. Adopt the Finance Write (Human-in-the-loop) template, set recovery_cost="high" on the gated function, and let high-cost calls queue. A reviewer approves with Session, so identical safe calls flow for the rest of the session - and re-prompt the moment the tool’s logic changes.

Measure before you enforce. Author a stricter policy, publish it, and set the workspace to Shadow. Watch the Would-deny if enforced tile for a day. When the divergence is acceptable, promote tier by tier to Enforce.

Next steps

• Virtual keys - bind agent identity, model allowlists, and budgets that policies can target.
• Teams & members - scope policies to teams and members and narrow allowed tools.
• MCP tool execution - govern tool calls brokered through MCP servers.
• Relationship Authorization (ReBAC) - add per-object access control with the relationship operand, and grant per-tool permissions, inspect tuples, and check access paths in ReBAC Studio.
• Guardrails - pair content guardrails with agentic authorization on the same hot path.
• Audit logs - platform-wide tamper-evident logging and evidence export.