Agentic Security - Best Practices

sachin_namjoshi

Purpose and scope

These standards applies to all ServiceNow-based AI agents, autonomous workflows, model-driven assistants, orchestration agents, and integrations that can reason over data, call tools, trigger actions, or access enterprise systems. It also applies to supporting components such as approved LLMs, MCP servers, connectors, data sources, service accounts, prompts, memory stores, and downstream APIs.

In scope: production agents, non-production agents with live-like data, vendor-provided agents, marketplace agents, workflow automations with model discretion, and agents interacting with IT, security, OT, or physical systems.
Out of scope: static automations with no model-based decisioning, except where they provide identity, logging, gating, or containment for in-scope agents.

Baseline principles

The following principles remain mandatory and should form the foundation for ServiceNow agentic security:

Minimum privilege: agents receive only the minimum permissions required.
Data minimization: only necessary data may be collected, processed, stored, or exposed to the model.
Secure by design: security must be built into planning, architecture, development, testing, deployment, and operations.
Transparency and explainability: agent behavior, inputs, actions, approvals, and connected components must be understandable enough to review and audit.
Human oversight and accountability: humans remain accountable for agent actions and must be able to intervene.
Continuous monitoring and improvement: controls must evolve with threat, usage, and operational changes.
Zero trust: every request, token, connection, and action must be explicitly verified and authorized.

ServiceNow agents must implement the following additions.

1. Continuous inventory and registration

No agent may run without a current system-of-record entry created as part of deployment. Manual after-the-fact inventory is not enough.

Every agent must be registered at deployment with its owner, purpose, environment, business criticality, connected model, tools, data sources, service identities, approval path, and retirement conditions.
Registration must be a deployment byproduct, not a separate manual task.
Inventory must include vendor and marketplace agents, embedded agents, and any agent operating in OT or physical contexts.
Changes to scope, permissions, model, tools, prompts, memory sources, or downstream integrations must update the record automatically or trigger review.

2. Mandatory automated deployment gates

Security review must block unsafe deployment, not merely advise against it.

Production promotion must be prevented unless required controls pass automatically.
Required checks include approved component use, completed inventory, identity assignment, data classification review, logging enablement, output controls, threat model completion, and vulnerability policy compliance.
Human approval may supplement a gate, but must not replace automated enforcement for required controls.
Model updates, prompt changes, connector additions, or privilege expansions must re-trigger the gate.

3. Named accountability across the enterprise

Shared responsibility is not enough without a named accountable leader and a per-agent owner.

A single enterprise wide accountable leader must own the framework, governance model, control quality, evidence expectations, and incident escalation path.
Each agent must have a named business owner and technical owner.
Security must have authority to block release, require containment, and revoke operation when controls are missing or risk is unacceptable.
Ownership must persist across handoffs, vendor changes, project closure, and team reorganization.

4. Non-human identity lifecycle control

Each agent is a non-human identity and must be governed that way.

Agents must use dedicated service identities. Shared human credentials are prohibited.
Secrets, API keys, and tokens must be stored securely, rotated regularly, and scoped narrowly.
Access must be time-bounded where possible and revalidated on change.
When access is revoked, confirmation must come from the target system, not only from the workflow that requested revocation.
Nested and inherited access must be reviewed so effective permissions are understood, not just assigned roles.

5. Continuous evidence and audit readiness

A posture that cannot be proven on demand is not defensible.

Approvals, configuration state, access scope, actions taken, and control outcomes must be captured continuously.
Evidence must answer: what the agent was allowed to do, what it actually did, who approved it, what data it touched, and what controls were active at the time.
Retention must support investigations, internal review, and regulatory needs; short-lived traces alone are insufficient.
Evidence must be searchable and exportable without reconstruction from disconnected systems.

6. Real-time monitoring with real response

Detection without containment is incomplete control.

Runtime monitoring must detect anomalous behavior, unusual access paths, excessive tool use, prompt injection indicators, and policy violations.
Critical detections must trigger automated response such as token revocation, connector disablement, action throttling, queue isolation, or kill switch invocation.
Human review remains required for recovery, exception handling, and high-risk re-enablement.

7. Kill switch and circuit breakers

Every agent must be stoppable quickly and safely.

A global or scoped kill switch must exist for each agent and high-risk integration path.
Circuit breakers must limit runaway execution, recursive loops, excessive spend, broad data extraction, or destructive action chains.
Fail-closed behavior must be defined for identity failure, policy lookup failure, model policy mismatch, or logging failure in critical contexts.

8. Approval integrity

Human approval only reduces risk when the action approved is exactly the action executed. Approval workflows must prevent loopjacking, where an agent or integration shows one action for approval and executes a different action after approval is granted.

Show the exact action: approval requests must display the complete normalized action, including tool or workflow name, target system, target record, operation, amount or quantity, recipient, parameters, data scope, and expected impact. Agent-written summaries may supplement but must not replace the canonical action view.
Lock the approved action: the exact action payload must be immutable after approval is requested. Any change to tool, target, parameter, amount, recipient, data scope, or execution context must cancel the approval and require a new approval.
Bind approval to execution: store a cryptographic fingerprint or equivalent tamper-evident identifier of the approved action with the approval record, approver identity, agent identity, timestamp, and expiry. Immediately before execution, recompute and compare the fingerprint. Any mismatch must fail closed.
Use one approval for one action: approvals must not be reused, transferred to sub-agents, applied to materially different actions, or used for unbounded batches unless every item in the batch is enumerated and locked before approval.
Protect pending approvals: agents, agent-to-agent messages, flows, callbacks, MCP tools, and downstream integrations must not be able to alter pending approved actions. If modification is technically possible, monitoring must detect it and containment must trigger automatically.
Separate approver authority: an agent, its service identity, or another automated identity must never approve its own high-impact action. Approver permissions must be checked at approval time and again before execution.
Capture evidence: logs must store the displayed action, approved action fingerprint, executed action fingerprint, approval decision, approver, agent identity, policy result, and execution result so reviewers can prove that the approved and executed actions matched.
Test for loopjacking: pre-release and regression testing must include misrepresentation and swap-after-approval scenarios, including attempts through agent-to-agent messaging, callbacks, Flow Designer changes, and external tool responses.

Control framework for ServiceNow agents

Design and approval controls

Define the agent objective, boundaries, approved actions, and prohibited actions before build starts.
Classify all data the agent may access and document minimization decisions.
Require human approval for high-impact actions such as privileged changes, mass updates, data deletion, user-impacting communications, or changes to security controls.
Allow only approved LLMs, MCP servers, tools, and external services.
Document trust boundaries, escalation paths, and fallback behavior.

Development controls

Validate and sanitize all inputs, including prompts, retrieved content, tool parameters, and user-supplied attachments.
Filter outputs for sensitive data leakage, unsafe action recommendations, and policy violations.
Scan code, dependencies, prompts, and integration packages for known vulnerabilities and unsafe patterns.
Implement secure error handling that avoids disclosing secrets, internal structure, or hidden policies.
Test prompt injection resistance, privilege boundary adherence, and abuse cases before release.

Deployment controls

Deploy agents in isolated environments with minimal external exposure.
Segment network and integration paths according to function and data sensitivity.
Use separate identities and environments for development, test, and production.
Enable centralized logging, policy decision capture, and configuration versioning before go-live.
Block deployment if mandatory records, approvals, or runtime controls are missing.

Runtime controls

Continuously verify identity, authorization, component approval, and connector scope.
Monitor action sequences, data access volume, tool invocation frequency, and privilege expansion attempts.
Rate-limit expensive or risky actions.
Require step-up approval when actions exceed pre-approved thresholds.
Review drift in prompts, tools, retrieval sources, or model behavior.

Incident response controls

Maintain an AI-specific incident response procedure covering containment, evidence preservation, credential revocation, communication, and recovery.
Classify incidents such as prompt injection, data leakage, privilege misuse, unregistered agent discovery, unauthorized connector use, and anomalous autonomy.
Preserve prompts, tool traces, configuration state, approvals, and access evidence for forensics.
Run post-incident review to update gates, detections, training, and policy.

Minimum mandatory requirements

The controls below should be treated as baseline requirements for production ServiceNow agents.

Every production agent is automatically registered before activation.

Each agent has a named business owner, technical owner, and accountable governance path.
Only approved models, tools, MCP servers, and data sources are allowed.
Dedicated non-human identities are used for all agent actions.
Secrets and tokens are vaulted, rotated, and scoped to least privilege.
Threat modeling and abuse-case review are complete before production release.
Human approval workflows display the complete canonical action, not only an agent-written summary, before approval is granted.
Approved high-impact actions are locked, bound to a tamper-evident fingerprint or equivalent identifier, and rechecked immediately before execution.
Approval changes, reuse, transfer to sub-agents, or unbounded batch execution are blocked unless every approved item is enumerated and locked.
Loopjacking tests cover misleading approval requests and swap-after-approval attempts through agents, flows, callbacks, and external tools.
Comprehensive logging and evidence capture are enabled and centrally available.
Real-time monitoring and automated containment exist for critical detections.
A tested kill switch exists for each high-risk agent or integration path.
Deprovisioning includes verification from downstream target systems.

Implementation Plan:

These controls and best practices can be implemented on service-now platform by configuring intake process for security governance requests. Workflow for these request could generate following artifacts:

- Threat model of governance request scope to include architecture and system description details.

- Regression and Pen Testing Tasks to avoid issues in code post deployment.

- Code Review Tasks to include following:

1. User Input validation and output encoding
2. End User Authentication logic
3. Gated handling of data (e.g.,tokens, PII)

- Compliance Review and Audit Tasks ( e.g Governance Request may contains PII, ISO etc data in scope) and additional scope may include :

1. Data classification and handling practices
2. User controls
3. Data logging, retention, encryption, and secure transmission practices
4. Third Party Dependencies

- Incident Response Plan Review and approval

- AI Review Tasks for security review of the use of Agentic solutions requests being submitted .The review should be intended to evaluate potential risks related to data confidentiality, access controls, model behavior, prompt injection, API usage, and other relevant vectors.

Bonus Tip : All of the above Governance Request Workflow tasks ( e.g Code Review, Regressions and Penetration Testing, Compliance Overview Tasks, AI components review tasks) should be made available to developers while they develop their apps which will reduce cycle time to approve these governance requests. This could be be different AI agents doing these tasks so that developers fix issues in their code beforehand.