Securing agentic AI: how NVIDIA, Atlassian and Glilot Capital describe guardrails for AI agents

Three documents, three vantage points

The question of how to secure autonomous AI agents looks different depending on who is answering it. The three documents behind this explainer come from three different positions.

• NVIDIA sells the components that agents run on. Its blog post, dated May 18, 2026, carries no named author.
• Atlassian ships an agent product, Rovo. Its security architecture is presented by the company's chief information security officer, David Cross.
• Glilot Capital built an agent for internal use. That work is described by Amit Spitzer, who holds both the chief technology officer and chief information security officer titles, in a post dated September 17, 2026.

Read together, they cover three layers: hardware and runtime, a vendor's software platform, and a small firm's own deployment.

NVIDIA's post frames the problem as a two-sided one, stating that "Enterprises must now take a dual approach: defend both with and against agentic AI." This explainer focuses on the second half of that framing: protecting the agents themselves.

NVIDIA: test before deployment, guard at runtime

NVIDIA's blog says the risk comes from what agents can do. They can reach tools, produce outputs with downstream effects and touch sensitive data. The post concludes that organizations need two kinds of control to keep agent behavior safe and predictable.

Pre-deployment testing. The blog describes red teaming and testing that go beyond prompt handling. It says this work also checks whether agents stay within constraints, recover from failures and withstand adversarial attacks. The post names Garak, which it calls a large language model vulnerability scanner. It says the tool automates agent testing by simulating attacks such as prompt injection, tool misuse and reasoning errors.

Runtime controls. The blog presents runtime guardrails as the second layer. It says they enforce policy boundaries, restrict unsafe behavior and bring agent outputs back in line with enterprise goals. The post identifies NVIDIA NeMo Guardrails as the software for defining and updating rules on what agents can say and do. It also names NVIDIA Confidential Computing for protecting data while it is being processed.

Supply chain integrity. For the components agents are built from, the blog lists three verification mechanisms included in its enterprise software stack: container signatures, model signing and a software bill of materials.

NVIDIA: isolation and attestation in the infrastructure

The NVIDIA post treats the infrastructure under an agent as part of the security problem. It ties the need for runtime workload protection, operational monitoring and strict zero-trust enforcement directly to agent autonomy.

The architecture choice it describes is where the security controls run. The blog says that running them on BlueField DPUs instead of on the server CPUs isolates threats at the infrastructure layer and reduces the blast radius of a compromise.

The blog also points to attestation. It says the infrastructure supports both local and remote attestation, so that customers can check platform integrity before placing sensitive workloads on it.

The post notes that the stakes rise when agents reach cyber-physical systems. In those settings, it says, a compromise can affect uptime, safety and the integrity of physical operations.

Atlassian: permission-aware agents and admin controls

David Cross's post announces the second edition of Atlassian's Rovo Security & Trust White Paper, which customers download from the company's Trust Portal. His summary of the paper centers on four themes: data handling, permissions, administrative control and threat detection.

Data handling. On data sent to model providers, the post says the paper explains Zero Data Retention. It describes how third-party providers handle prompts without storing them or training on them.

Permissions. The design decision the post stresses most is whose access rights an agent uses. According to the post, Rovo Search, Chat and Agents link knowledge across Jira, Confluence and connected third-party apps. They do so while honoring the permissions of the person using them, not those of whoever built the agent. The post says this permission-aware approach extends across Atlassian apps and more than 50 Teamwork Graph connectors.

Administrative control. The post lists the controls the paper covers: Rovo Access allowlists and blocklists, an option for Atlassian-hosted models, data residency, IP allowlisting, customer-managed keys and agent governance. In practical terms, the post says admins can:

• limit AI to selected user groups
• choose which third-party tools connect
• keep data at rest in a chosen region
• monitor usage through dashboards and audit logs

Threat detection and compliance. The post says the paper covers how Atlassian finds abuse, prompt injection and unusual access patterns. On compliance, it lists the following certifications: SOC 2 Type II, ISO 27001, ISO 27018 and ISO 22301. It also notes progress toward ISO 42001, the AI management system standard.

The post also recommends a staged rollout, suggesting customers turn Rovo on in a sandbox and test its features before broad deployment.

Glilot Capital: a read-only agent first

Amit Spitzer's post describes an agent built by the firm for its own use rather than one sold to customers. He says the project began with a knowledge problem. The firm's institutional knowledge was spread across separate systems, which caused data quality issues.

The resulting agent, Eliot, sits on top of the firm's internal platform, GlilotOS. The post says it draws on all of the firm's data sources, from relationship management and file sharing to internal chat.

The control choice Spitzer describes is a limit on what the agent can do, not a separate guardrail product. The post says Eliot, still in beta, only answers read-only queries for now. Generative functions such as drafting emails are held back until stability and accuracy are established.

The post presents the project as consistent with the firm's investment focus. It says the firm, which invests in AI and cybersecurity, thinks it should demonstrate the approach itself.

Where the descriptions overlap and differ

The documents work at different layers and do not cite one another, but several themes recur:

• Prompt injection. NVIDIA names it as a test target for Garak, and Atlassian names it as something its threat detection looks for.
• Limiting agent authority. Each source restricts what an agent may do, in a different way:
  • NVIDIA describes guardrails that enforce policy boundaries at runtime.
  • Atlassian ties agent access to the end user's permissions.
  • Glilot limits its agent to read-only queries during beta.
• Staged adoption. NVIDIA's pre-deployment testing, Atlassian's sandbox recommendation and Glilot's beta phase each put a step between building an agent and giving it full operation.

The differences follow from each author's position:

• NVIDIA focuses on infrastructure isolation, attestation and supply chain signing.
• Atlassian focuses on admin settings, data retention terms with model providers and compliance certifications that a buyer's security team would review.
• Glilot, a firm building for itself, describes scope limits and the data sources the agent connects to.