Before you give an AI agent access to your company’s systems

Control 01

Define the agent’s mission before choosing the technology

The task area must be defined for the agent, i.e. mission envelope.

Document at least:

• what business task the agent performs
• from which sources it can receive information
• what information it can read
• what tools it can use
• what changes it can make
• which actions it must never perform
• how long one task can continue
• how many tool calls the task can generate
• how much money or computing capacity it can use
• when the operation must be stopped.

“Handle customer service” is too broad a goal.

A more precise goal could be:

Classify incoming support request.
Get the customer's contract level from the customer API.
Create a draft answer.
Do not send a message.
Do not change customer information.
Do not open attachments in the runtime environment.
Stop after up to five tool calls.

The more precisely the task can be described, the more precisely the technical boundaries can be built for it.

Control 02

Name an owner, approver and kill-switch operator

The agent must have a designated business owner.

In addition, you must specify:

• who approves the systems used by the agent
• who approves its access permissions
• who monitors the activity
• who handles incidents
• who can stop the agent
• who decides to reinstate the agent.

NCSC emphasises that humans remain responsible for deploying an agent, the permissions granted to it, the controls surrounding it and the consequences of its actions. Responsibilities should be clear before the agent is connected to real systems or data. [1]

The owner of the agent may not be the same person as the technical administrator of the agent. The business owns the decision about what the agent is allowed to do. Security and IT are responsible for the controls that implement the decision.

Control 03

Give the agent its own identity

Each agent or distinct agent type should have its own workload identity.

For example:

tag:invoice-reader
tag:invoice-drafter
tag:support-classifier
tag:code-review-agent
tag:deployment-agent

The same identity should not be used for the read agent and the production change agent. Otherwise, their permissions, logging and life cycle cannot be distinguished reliably.

Different environments of the agent must also be distinguished:

tag:invoice-agent-dev
tag:invoice-agent-test
tag:invoice-agent-prod

In Tailscale, tags identify servers, containers, automation and other non-personal devices. tagOwners controls who may assign a tag through normal delegated workflows; tailnet Owners, Admins and Network admins can apply any tag as part of their administrative role. [4]

Control 04

Use short-lived and purpose-bound credentials

A persistent API key is dangerous, especially in an agent environment where information flows between prompts, memories, logs, tool responses, and different agents.

Credentials should not be:

• added to the system prompt
• stored in the agent’s long-term memory
• returned to the model in a tool response
• shared between multiple agents
• placed in an unprotected environment variable
• written to logs.

When supported by the platform, the workload should prove its identity through OIDC and exchange this proof for a short-lived token with narrowly configured scopes.

Tailscale Workload Identity Federation lets a workload exchange a platform-signed OIDC identity token for a short-lived Tailscale API token with configured scopes. Tailscale validates the signature, issuer, audience, expiry and configured claim-matching rules. The resulting token can be used with the Tailscale API and, when granted the required scope, to register a node; it is not a credential for the target business application. [5]

Tailscale identity and business-application access remain separate. The agent can use its Tailscale identity to establish an authorised network connection, but the target application must still authenticate and authorise the API operation itself.

Control 05

Limit network connections with the deny-by-default principle

The agent should not automatically have a connection to the entire internal network.

Network access must be defined explicitly:

Which agent?
To which service?
With what protocol?
On which port?
In which direction?

For example, a billing agent may need an HTTPS connection to the billing API. It therefore does not need to connect to:

• production database
• DNS and domain management
• employee endpoints
• backup servers
• SSH management
• other agents.

The Grants rule model is deny-by-default: a connection is allowed only if the complete tailnet policy contains a matching source, destination and network capability. Rules are additive, so another overbroad Grant can expand the permissions of a tightly scoped agent. A newly created tailnet can include a pre-populated allow-all policy, which must be replaced before this least-privilege assumption is true. [6]

Control 06

Separate network access, tool access and application permissions

Network connection to the service must not automatically mean the permission to perform all operations exposed by the service.

Secure authorisation consists of at least three layers:

1. Network policyCan the agent reach the service?
2. Tool PolicyIs the agent allowed to call this tool?
3. Application PolicyWhat is the agent allowed to do inside the service?

Tailscale can, for example, allow the agent to connect to the billing API on TCP port 443. However, a standard network-level Grant alone does not differentiate between the following HTTP operations:

GET    /invoices/7421
POST   /invoices/7421/draft
POST   /payments
DELETE /suppliers/91

This boundary must be enforced in the API gateway, tool broker or application itself. As the Defense First Tailscale guide explains, a Grant allows a network capability, while the application still enforces its own read, write and administrative permissions. [7]

Control 07

Only allow named tools and validated parameters

An agent should not be free to choose any tool it finds in the environment.

The tools should be divided into at least the following categories:

Tool selection alone is not enough. The parameters must also be validated outside the agent.

For example, a secure scope for an email tool might include:

Allowed Recipients:
only @customer.example

Maximum recipients:
1

Attachments:
not allowed

Data classification:
public or internal only

Sending:
requires human approval

MCP server should not be treated as a harmless add-on. It is practically an API and tool interface through which the agent can gain new abilities. The MCP server, its tools, versions, owner and usage permissions must be treated with the same seriousness as other production interfaces.

Third-party tools expand an agent’s software supply chain and attack surface. International government guidance recommends an approved tool list, version control, tool-call logging and preventing agents from changing their own permissions. [2]

Control 08

Restrict internet egress as well

Restricting internal network paths alone does not prevent data from being taken out of the company.

Tailscale routes traffic belonging to tailnet by default. The agent's ordinary internet traffic can still go through the default network route of the operating system or cloud platform. Therefore, the Tailscale Grant alone does not prevent an agent from connecting to an external service. [8]

Internet egress must be restricted separately when necessary, for example:

• with cloud platform firewall or security group rules
• with Kubernetes NetworkPolicy
• with the firewall of the operating system
• with a separate network namespace
• with an egress proxy
• with a DNS and domain allowlist
• with a controlled exit node connected to an egress firewall
• with a DLP or API gateway solution.

For example, the egress policy can allow the agent to reach only the following external destinations:

api.openai.com:443
api.anthropic.com:443
approved enterprise SaaS API:443

Simply allowing port 443 everywhere is not a significant limitation, since almost all modern outgoing traffic uses HTTPS.

Control 09

Require human approval for high-impact actions

Human approval is not just about a button that says “Accept agent proposal”.

The approver must be shown the exact action:

• target system
• resource
• action type
• values to be changed
• old and new state
• recipient
• amount
• identity to be used
• validity period of approval.

Approval should be tied to these parameters. If the agent changes the amount, recipient or destination of the payment after approval, the approval must no longer be valid.

For example:

{
  "agent": "invoice-agent",
  "action": "create-payment",
  "invoice": "7421",
  "recipient": "FI00 0000 0000 0000 00",
  "amount_eur": 1240.00,
  "approved_by": "controller@example.com",
  "expires_in_seconds": 300
}

Only a summary generated by the agent itself is not a sufficient approval view. OWASP recognizes the risk that a persuasive and elaborate agent explanation leads a human to approve a malicious action. [3]

In high-risk operations, the approval view should therefore be based on a deterministically generated diff or event object, not just the agent's verbal description.

Control 10

Isolate the agent's execution environment and limit resources

The agent should be run in an environment where the compromise of a single process or tool does not open the entire host system.

Practical controls include:

• separate virtual machine or container
• read-only root file system
• only named writable directories
• no access to Docker socket
• no use of the host network without justified need
• restricted Linux capabilities permissions
• CPU and memory limits
• maximum number of tool calls
• timeout
• concurrency limit
• cost budget
• loop detection
• automatic circuit breaker.

The agent must fail safely.

If the authorisation service, approval system or logging is unavailable, the high-risk operation should not be performed. If the agent's activity volume deviates from normal, its permissions can be reduced or the workload can be quarantined.

Government guidance recommends testing agents in isolated environments, setting operational and resource limits, providing recovery mechanisms and automatically reducing permissions when behaviour becomes anomalous. [2]

Control 11

Also test what must fail

A successful connection does not prove a secure architecture.

Agent acceptance tests must include both allowed and denied cases.

Tailscale supports policy tests to verify that a specified source can connect to an allowed destination and that named other connections are blocked. Tests can be stored in the same tailnet policy with Grants rules. [9]

However, the policy test does not replace a production end-to-end test. In addition to the network test, the application's authentication, API permissions, approval, logging and the kill switch must be tested.

Control 12

Log, monitor, revoke and recover

Each production run of the agent should form a correlatable chain of events.

Useful information includes:

• the unique identity of the agent
• the person or system that requested the task
• the run ID of the task
• the agent and model version used
• the policy version used
• tool calls
• essential parameters of calls
• authorisation decisions
• approvals
• target systems
• metadata of network connections
• results and errors
• spent time and cost
• reason for interruption.

Confidential inputs, credentials or entire model contexts should not be saved automatically without a separate data protection and information security assessment.

Tailscale configuration audit logging records who or what changed the tailnet's settings, what changed and when; policy changes include a diff between the old and new versions. Network flow logs record flow metadata rather than traffic content, are currently available on Premium and Enterprise plans, retain the most recent 30 days in Tailscale and do not provide a complete record of denied connection attempts. [10] [20]

Tailscale logs alone do not tell what the agent did inside the application. Therefore, the logs of the agent framework, tool broker, API gateway, application and network layer must be connected using the same run ID or other correlation ID.

The kill switch should at least be able to:

1. stop the agent's workload
2. remove its network access
3. revoke application tokens
4. block new tool calls
5. retain the logs necessary for the investigation
6. restore the changes made by the agent when possible.