Fortisase Audit

• Outcome: Review
• Latest audit: Sep 16, 2026 · 4:23 AM UTC
• Version: 1.0.0

Overview

The skill is a coherent FortiSASE audit guide, but it should go to Review because it normalizes handling reusable FortiCloud and FortiGate administrator credentials without adequate safeguards.

Install only if operators will use dedicated read-only service accounts or scoped API tokens, keep all tokens and passwords out of prompts, logs, command history, and reports, and avoid direct FortiGate administrator authentication unless it is strictly necessary and locked down with least privilege and trusted-host controls.

A.I.G

Vulnerability Patterns

• Insecure Skill Coding Practices: Finds exploitable flaws such as hardcoded secrets or command injection
• Skill Instruction Hijacking: Alters the agent's session goals or safety constraints when the skill loads
• Agent Memory Poisoning: Writes attacker-controlled rules into memory that affect later sessions
• Remote Payload Retrieval and Execution: Fetches external code whose behavior can change after review
• Embedded Malicious Code: Ships malicious scripts inside the skill and executes them locally

Findings (2)

T09 · Insecure Skill Coding Practices

Warning

• Location: SKILL.md:64
• Finding: FortiCloud password-based authentication exposes reusable account credentials<![CDATA[ ## Vulnerability Details **File Location**: `SKILL.md`, lines 64-72 **Vulnerability Type**: T09: Insecure Skill Coding Practices **Risk Level**: Medium ### Vulnerable Code ```text # Authenticate to FortiCloud and obtain bearer token POST https://customerapiauth.fortinet.com/api/v1/oauth/token/ Content-Type: application/json { "username": "<forticloud_user>", "password": "<forticloud_pass>", "client_id": "<api_client_id>", "grant_type": "password" } ``` ### Technical Analysis The skill declares `FORTISASE_API_TOKEN` as its required secret and describes read-only access as a prerequisite, but its main procedure instructs the operator or agent to handle a reusable FortiCloud username and password through the OAuth resource-owner password grant. Although the example contains placeholders rather than hardcoded credentials, following these instructions would place the real password in an agent-generated HTTP request body. Depending on the execution environment, sensitive request data could be retained in conversation records, tracing systems, debug logs, proxy logs, terminal history, or error reports. A reusable account password has a substantially larger security scope than a dedicated, revocable, read-only API token. It can also be usable outside the intended audit workflow and may grant access to other FortiCloud resources according to the account's IAM roles. ### Attack Path 1. An operator loads the skill and follows the documented authentication procedure. 2. The operator provides a FortiCloud username, password, and client identifier to the agent or an agent-controlled request tool. 3. The request body or surrounding execution context is retained in a prompt transcript, request trace, debug log, proxy log, or error report. 4. An attacker or unauthorized user obtains access to that retained record. 5. The attacker extracts the reusable FortiCloud credentials. 6. The attacker authenticates as the affected account and accesses FortiSASE or ...[truncated 861 chars]
• Remediation: <![CDATA[ ## Remediation Suggestions 1. Remove the username/password authentication procedure from the skill. 2. Require a dedicated FortiCloud service account with only the IAM read permissions needed by the audit. 3. Use a short-lived or explicitly revocable API token supplied through `FORTISASE_API_TOKEN`, as declared in the skill metadata. 4. Retrieve secrets only from protected environment variables or an approved secret manager; never ask users to paste passwords into prompts. 5. Prevent authorization headers, tokens, passwords, refresh tokens, and request bodies from appearing in logs or traces. 6. Document token expiration, revocation, and rotation procedures. 7. Add an explicit warning that personal FortiCloud accounts and reusable passwords must not be used. 8. Ensure the authentication endpoint is included in the declared egress policy if it remains necessary. ]]>

T09 · Insecure Skill Coding Practices

Warning

• Location: references/api-reference.md:315
• Finding: Direct thin-edge authentication requires reusable device administrator credentials<![CDATA[ ## Vulnerability Details **File Location**: `references/api-reference.md`, lines 315-325 **Vulnerability Type**: T09: Insecure Skill Coding Practices **Risk Level**: Medium ### Vulnerable Code ```text ### Direct Thin Edge Authentication # Obtain session token from thin edge FortiGate POST https://<thin_edge_ip>/api/v2/authentication Content-Type: application/json { "username": "<admin_user>", "secretkey": "<admin_password>" } Response includes a session cookie or API token for subsequent requests. ``` ### Technical Analysis The reference instructs the agent to authenticate directly to a thin-edge FortiGate by handling an administrator username and password. This conflicts with the least-privilege posture expected of a read-only audit and expands secret handling beyond the declared `FORTISASE_API_TOKEN`. Even though HTTPS protects the credential in transit when certificate validation is correctly enforced, it does not prevent exposure through the agent context, request tracing, debugging output, local logs, proxy inspection, or error reporting. Device administrator passwords are reusable secrets and may permit configuration changes, unlike a narrowly scoped monitoring token. The instructions also do not require: - A read-only FortiGate administrator profile - A dedicated REST API administrator - Trusted-host restrictions - Token expiration or rotation - TLS certificate validation - Secret redaction from logs Consequently, an operator may use a full administrator account for a task that only needs read access. ### Attack Path 1. The operator performs a thin-edge policy consistency or status check using the documented direct-authentication method. 2. A FortiGate administrator username and password are supplied to the agent or request tool. 3. The request body or execution context is captured in a transcript, debug trace, terminal record, proxy log, or error report. 4. An attacker with access to the captured data obtains the reusable devic ...[truncated 1174 chars]
• Remediation: <![CDATA[ ## Remediation Suggestions 1. Replace password-based direct authentication with a dedicated FortiGate REST API administrator token. 2. Assign a custom read-only administrator profile containing only the monitoring and CMDB permissions required by the audit. 3. Restrict the API administrator with trusted-host allowlists and management-interface access controls. 4. Store the token in a secret manager or protected environment variable rather than prompts, source files, or command-line arguments. 5. Redact authentication bodies, authorization headers, session cookies, and API tokens from all logs and traces. 6. Enforce TLS certificate validation and reject self-signed or mismatched certificates unless trust has been established out of band. 7. Rotate the token regularly and revoke it immediately after suspected exposure. 8. Prefer the centralized FortiSASE read-only management API when it provides the required information, avoiding direct device authentication entirely. 9. Explicitly prohibit use of full-access or shared administrator accounts for audit operations. ]]>

SkillSpector

Vulnerability Patterns

• Prompt Injection: Instruction Override, Hidden Instructions, Exfiltration Commands
• Data Exfiltration: External Transmission, Env Variable Harvesting, File System Enumeration
• YARA Signatures: Malware Match, Webshell Match, Cryptominer Match
• Privilege Escalation: Excessive Permissions, Sudo/Root Execution, Credential Access
• Supply Chain: Unpinned Dependencies, External Script Fetching, Obfuscated Code

Findings (6)

YARA rule 'agent_skill_prompt_injection_hidden_instructions': Prompt injection or hidden instructions embedded in AI agent skill text [agent_skills]

High

• Category: YARA Match

Content

S server address, ZTNA tag definitions, compliance rule sets, and endpoint group assignments
- FortiGuard subscription status — which services are licensed (FortiGuard AV, IPS, Web Filter, Application Control, DNS Filter, Inline CASB, DLP)
- Knowledge of expected SWG and ZTNA policy baselines for comparison against current configuration
- Network diagram or inventory showing thin edge FortiGate models, firmware targets, and SD-WAN SLA definitions

## Procedure

Follow this audit flow sequentially. Each step builds on prior findings.
The procedure moves from tenant discovery through SWG policy analysis, ZTNA
assessment, firewall policy review, thin edge validation, SSL inspection,
endpoint compliance, FortiGuard health, and logging infrastructure.

### Step 1: Tenant and Topology Discovery

Authenticate to the FortiSASE API via FortiCloud IAM and enumerate the
tenant topology.

```
# Authenticate to FortiCloud and obtain bearer token
POST https://customerapiauth.fortinet.com/api/v1/oa

• Confidence: 80% confidence
• Finding: YARA rule matched a hack tool or exploit indicator (offensive tools, reconnaissance, privilege escalation, or exploit frameworks).

Instruction Override

High

• Category: Prompt Injection

Content

finding.
- **SD-WAN overlay configuration:** Review SD-WAN SLA definitions (latency,
  jitter, packet loss thresholds). Verify health-check targets are reachable
  and meaningful. Check that SLA violation failover does not bypass security
  inspection.
- **Security policy consistency:** Compare the thin edge local firewall policy
  with the FortiSASE cloud policy. Identify discrepancies where thin edge

• Confidence: 90% confidence
• Finding: This pattern attempts to override system instructions or ignore safety constraints. Without LLM analysis, manual review is recommended.

Missing User Warnings

Medium

• Confidence: 88% confidence
• Finding: The skill explicitly requires an API token and discusses privileged tenant audit access, but it does not include prominent handling guidance for secrets or warnings about exposing sensitive tenant configuration data. In a real agent workflow, this increases the chance that operators paste credentials into prompts, logs, shell history, or transcripts, leading to credential leakage and unintended disclosure of security posture data.

Missing User Warnings

Medium

• Confidence: 95% confidence
• Finding: The authentication example uses direct username/password submission to obtain a bearer token without cautioning against interactive credential use, logging, or shell/history exposure. This normalizes unsafe secret handling and can cause compromise of FortiCloud credentials or session tokens if copied into tools, transcripts, or debug output.

Missing User Warnings

Medium

• Confidence: 94% confidence
• Finding: The documentation provides concrete authentication request/response examples containing usernames, passwords, access tokens, and refresh tokens without any warning to treat them as secrets, avoid logging them, or use safer auth flows. In an audit skill that programmatically accesses tenant security posture and policy data, this can normalize unsafe credential handling and lead operators or downstream agents to expose high-value tokens in code, transcripts, or logs.

Missing User Warnings

Medium

• Confidence: 96% confidence
• Finding: The direct thin-edge authentication section instructs use of privileged FortiGate admin credentials and session tokens but omits safeguards around credential minimization, token storage, session invalidation, and restricting management-plane access. Because these are direct device admin interfaces, mishandling can expose control of edge firewalls, enabling policy tampering, lateral movement, or persistent compromise.

Static analysis

No suspicious patterns detected.