The security conversation changes when AI moves from answering questions to taking actions.
A chatbot may generate an incorrect response.
An autonomous agent may execute code, modify a repository, call an API, query customer data, invoke an MCP tool, use cloud credentials, restart infrastructure, or send information to an external service.
That does not mean enterprises should avoid agents.
It means the production-readiness review needs to reflect what agents are actually capable of doing.
Here are twelve questions CISOs should ask before approving an autonomous agent for production use.
1. What can this agent actually do?
Do not accept descriptions such as:
It helps engineers.
Ask for a capability map.
Agent
+-- Filesystem: project RW
+-- Shell: yes
+-- GitHub: repo A RW
+-- Jira: project ENG read
+-- Cloud: none
+-- MCP: GitHub server
`-- Internet: approved endpoints only
If nobody can produce this map, nobody fully understands the blast radius.
2. Which enterprise systems can it reach?
Inventory source repositories, databases, cloud accounts, SaaS applications, internal APIs, production platforms, CI/CD, and customer systems.
Then classify each system by sensitivity.
Risk is a function of both agent capability and resource value.
3. What credentials does it possess?
Ask whether the agent can directly see API keys, PATs, cloud credentials, database passwords, OAuth refresh tokens, SSH keys, or kubeconfigs.
Prefer workload identity, scoped short-lived credentials, and credential mediation.
If the agent has raw secrets, understand exactly why.
4. Can the agent reach arbitrary internet destinations?
This may be the simplest high-value question.
If the answer is yes, ask:
Why?
An autonomous agent with access to sensitive data and unrestricted egress has a straightforward exfiltration path.
A production agent should ideally have an explicit destination allowlist.
5. Where does model inference occur?
Identify provider, endpoint, model, data classes, retention terms, geographic restrictions, and whether private inference is required.
Do not assume all agents should use the same model path.
Sensitive workloads may require private endpoints or self-hosted inference.
6. What happens if prompt injection succeeds?
Do not ask only:
Can prompt injection be prevented?
Assume the model eventually follows a malicious instruction.
Then ask:
What can the attacker cause the agent to do?
If the answer is "read production secrets, call arbitrary internet endpoints, and invoke destructive tools," the architecture is fragile.
Security should limit impact even when model behavior fails.
7. How are MCP servers and tools governed?
Ask:
- Which MCP servers are approved?
- Who owns them?
- Which tools do they expose?
- Which agents can call each tool?
- Which tools are destructive?
- What identity is used downstream?
- Are calls logged?
Treat MCP tools as permissions.
8. Is the agent isolated from the user's workstation?
If a coding agent executes directly on a developer laptop, it may inherit access to SSH keys, cloud sessions, browser tokens, VPN connectivity, kubeconfigs, and unrelated repositories.
Ask whether agents run in dedicated sandboxes, containers, VMs, or controlled remote environments.
9. Can security revoke capabilities centrally?
Security should not need an application release to remove agent access.
Ask whether teams can centrally revoke credentials, detach providers, change network policy, disable tools, remove workspace access, or terminate sandboxes.
This becomes critical during incident response.
10. Are agent policies version-controlled?
Agent access changes are security changes.
Treat them like IAM changes, firewall changes, and infrastructure changes.
Use Git, pull requests, code owners, approvals, and tests.
If policy exists only in a UI or developer laptop, governance will become difficult at scale.
11. Can we reconstruct what the agent did?
During an incident, the SOC should be able to answer:
Who launched it?
Which identity did it use?
Which systems did it access?
Which tool did it invoke?
Which requests were denied?
Which model handled the request?
Which policy was active?
Agent observability needs to integrate into the existing security program.
OpenShell supports sandbox logs and OCSF JSON export for downstream security tooling.
12. Have we tested what the agent cannot do?
A positive demo proves usefulness.
A negative test proves security.
Before production, attempt:
[ ] unapproved network destination
[ ] restricted file
[ ] raw credential access
[ ] unauthorized MCP tool
[ ] prohibited cloud action
[ ] privilege escalation
[ ] unapproved model provider
Capture evidence.
If the only acceptance test is "the agent completed the task," the security test is incomplete.
Ask for an agent threat model
Every privileged autonomous workload should have a threat model proportionate to its risk.
The model should cover prompt injection, credential theft, data exfiltration, excessive agency, tool abuse, MCP compromise, supply-chain compromise, privilege escalation, model-provider exposure, and audit gaps.
Most importantly, connect threats to actual capabilities.
Ask for a target architecture
A production agent should live inside an intentional security architecture.
Enterprise Identity
|
v
Agent Platform
|
v
Secure Runtime
/ | \
/ | \
files network credentials
\ | /
\ | /
v v v
Approved Tools
|
v
Enterprise Systems
The agent should not be the security perimeter.
Where OpenShell fits
NVIDIA OpenShell is designed for secure autonomous execution.
It combines sandboxing and declarative policy around filesystem, process identity, network egress, provider credentials, workspaces, and inference.
Its architecture separates policy/state in the Gateway from enforcement in each sandbox.
For CISOs, the important idea is not the product name. It is the control model:
Agent permissions are enforced outside the agent.
Establish production gates
Before approving a privileged agent, require evidence for:
- named business and technical ownership;
- documented capability map;
- reviewed threat model;
- least-privilege permissions;
- dedicated identity;
- scoped credentials;
- controlled egress;
- approved data flows;
- governed tool access;
- central logging;
- incident-response kill/revoke capability;
- negative security tests.
That creates a repeatable review process rather than one-off exceptions.
The strategic question
The enterprise will almost certainly run more autonomous software over time.
So the long-term CISO question is not:
How do I approve this one agent?
It is:
What control plane will govern the next hundred agents?
That is where agent inventory, reusable policy, secure runtime infrastructure, and centralized observability become strategic platform concerns.
How Anpu Labs helps
Anpu Labs helps CISOs and engineering leaders establish that foundation.
Our Secure Agent Infrastructure Assessment inventories agents, maps systems and credentials, builds a capability map, threat-models the environment, assesses current controls, designs the target architecture, recommends a bounded pilot, and produces the implementation backlog.
The outcome is a practical path toward autonomous AI without uncontrolled enterprise access.
References
- NVIDIA OpenShell — Overview: https://docs.nvidia.com/openshell/latest/about/overview
- NVIDIA OpenShell — How OpenShell Works: https://docs.nvidia.com/openshell/about/how-it-works
- NVIDIA OpenShell — Workspaces: https://docs.nvidia.com/openshell/latest/how-it-works/workspaces
- NVIDIA OpenShell — Providers: https://docs.nvidia.com/openshell/how-it-works/providers/overview
