Agent Security

AI agents execute multi-turn tool call chains across MCP servers, databases, and external APIs. Arbitex provides session auditing, tool authorization, and risk scoring for agent workloads.

Agent security extends MCP Governance — MCP governance controls individual tool calls, while agent security governs the full multi-turn session lifecycle.

---

Agent session model

An agent session is a multi-turn conversation where an LLM makes tool calls across one or more MCP servers. Every event in a session shares a session_id that links the complete chain of actions.

Session data model

The agent_audit_sessions table stores session metadata:

Field	Type	Description
id	UUID	Session identifier
org_id	UUID	Tenant isolation
user_id	UUID	User who initiated the session
agent_identity_id	UUID	Agent identity reference (nullable)
name	string	Human-readable session name
status	string	active, completed, or terminated
session_risk_score	float	Aggregated risk score (0.0–1.0)
event_count	integer	Count of linked audit events
risk_signals	JSONB	Breakdown of risk signal counts
created_at	datetime	Session start time
completed_at	datetime	Session end time (nullable)

Session ID propagation

The agent_session_id column on the audit_logs table links audit events to their parent session. This enables timeline reconstruction across all events in a session — tool calls, DLP findings, policy decisions, and model responses.

Session management API

Method	Path	Description
POST	/api/v1/admin/agent-sessions	Create a new session
GET	/api/v1/admin/agent-sessions	List sessions (filterable by status, user_id, date_from, date_to)
GET	/api/v1/admin/agent-sessions/{session_id}	Get session with full event timeline
PATCH	/api/v1/admin/agent-sessions/{session_id}	Update session status or name

Session timeline

The GET endpoint for a specific session returns the session metadata plus a chronological timeline of all linked audit events:

curl "https://your-platform/api/v1/admin/agent-sessions/{session_id}" \
  -H "Authorization: Bearer $ADMIN_TOKEN"

Each event in the timeline includes: id, action, model_id, provider, token_count_input, token_count_output, cost_estimate, latency_ms, and created_at.

---

Per-agent tool authorization

Tool authorization is currently enforced at the MCP server level through tool allowlists and blocklists on each registered server. Different agents can be given different access by:

1. Per-MCP-server tool lists: Each registered MCP server has allowed_tools and blocked_tools JSONB columns. Configure these per server to control which tools are available. See MCP Governance — Tool allowlists.

2. Policy rules with mcp_server conditions: Create policy rules that target specific MCP servers. Agents operating through different servers see different policy outcomes.

3. Group-based policy conditions: Agents operating under different user groups inherit different policy rules. An agent running as a user in the “trusted-agents” group sees different enforcement than one in the “restricted-agents” group.

4. Product-type conditions: The product condition in policy rules can target mcp_tool traffic specifically, separate from ai_chat interactive traffic.

Note

The agent_identity_id field on sessions is a placeholder for a planned per-agent-identity authorization model. Currently, tool authorization is achieved through per-server tool lists and group-based policy rules.

---

Chain-of-thought capture

The audit trail’s extra_metadata JSONB field can store arbitrary structured data per event, including model reasoning traces when available. This provides a storage path for chain-of-thought data from AI models that expose reasoning tokens.

Note

Chain-of-thought capture depends on the AI model provider exposing reasoning tokens. Not all models or providers support this. The extra_metadata field on audit events accommodates reasoning data when it is available from the model response.

Chain-of-thought data stored in extra_metadata is subject to the same BYOK encryption as other audit fields when BYOK is enabled for the org. See BYOK Encryption.

---

Session risk scoring

Each agent session carries a session_risk_score (float, 0.0–1.0) and a risk_signals JSONB breakdown. The platform also provides request-level risk scores that feed into session-level assessment.

Request-level risk signals

The policy engine evaluates three risk dimensions on each request:

Score	Source	Description
user_risk_score	CredInt/GeoIP enrichment	User risk based on credential exposure frequency and IP reputation
adversarial_risk_score	DLP adversarial detection	Prompt injection and adversarial threat score
cumulative_risk_score	Multi-turn analysis	Session-level cumulative risk

These scores are stored in audit event extra_metadata and can be used as policy conditions: user_risk_score_min, adversarial_risk_score_min, and cumulative_risk_score_min set threshold-based triggers on policy rules.

Session-level risk

The session_risk_score on the agent session record aggregates risk signals across all events in the session. The risk_signals JSONB field provides a breakdown of contributing factors.

Risk score ranges

Score range	Level	Description
0.0 – 0.3	Low	Normal agent behavior
0.3 – 0.6	Medium	Elevated risk — review recommended
0.6 – 0.8	High	Suspicious patterns detected
0.8 – 1.0	Critical	Likely policy violation or data exfiltration attempt

Policy-based alerting

Risk scores trigger policy actions when configured thresholds are exceeded. Create policy rules with risk score conditions to block, flag, or webhook-alert on suspicious agent behavior:

{
  "name": "Block high-risk agent sessions",
  "conditions": {
    "adversarial_risk_score_min": 0.7
  },
  "action": {
    "type": "block",
    "message": "Request blocked due to high adversarial risk score"
  }
}

---

Guardian Agent capabilities

Arbitex implements guardian capabilities as inline policy enforcement within the existing platform — not as a separate agent process. This aligns with the Gartner-defined Guardian Agent category while leveraging the platform’s existing security infrastructure:

Capability	Implementation
Tool call interception	Policy engine evaluates every tool call before execution
Data flow monitoring	DLP pipeline scans all tool inputs and outputs
Session-level oversight	Risk scoring across the full session timeline
Tool authorization	Per-server tool allowlists/blocklists
Audit trail	Complete tool call history with policy decisions
Anomaly detection	Risk scoring flags unusual patterns via policy rules

OWASP Agentic AI alignment

The agent security model addresses several risks from the OWASP Top 10 for Agentic Applications:

OWASP Risk	Arbitex Control
Excessive Agency	Per-server tool allowlists limit available actions
Insecure Tool Use	Policy engine + DLP scan on every tool call
Memory Poisoning	Audit trail captures state mutations from tool outputs
Prompt Injection via Tools	DLP pipeline scans tool responses before context injection
Insufficient Logging	Session-level audit with full event timelines

---

Cloud portal agent session viewer

The Cloud portal provides an agent session viewer at Admin > Agent Sessions with:

• Session list: filterable by status, user, time range
• Session timeline: chronological list of tool calls with policy decisions at each step
• Risk breakdown: session risk score and contributing signals
• DLP findings: sensitive data detections across the session

---

Related

• MCP Governance — MCP server registration, per-server policy rules, Security API
• Policy Engine — rule evaluation model and action types
• Security Architecture — defense-in-depth model
• Compliance Frameworks — compliance bundle integration with agent auditing