Sara: Safety Ordering Guard for AI Skills

• Outcome: Pass
• Latest audit: Sep 16, 2026 · 5:45 AM UTC
• Version: 1.0.0

Overview

Sara is a local advisory safety guard with no hidden data access or persistence, but its audit should not be treated as a complete safety gate for risky actions.

Sara is reasonable to install as a lightweight local reminder, but do not treat it as an authoritative safety decision. For deletion, publishing, payment, booking, permission, or sensitive-data workflows, independently verify prerequisites such as backups, previews, checks, and user approval even when Sara reports the plan as safe.

A.I.G

Vulnerability Patterns

• Tool Hijacking and Spoofing: Modifies or replaces tools so legitimate-looking calls execute attacker logic
• 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

Findings (3)

T09 · Insecure Skill Coding Practices

Error

• Location: sara_core/engine.py:225

Finding

Missing Safety Prerequisites Are Treated as Safe

Content

View full analysis

Vulnerability Details

File Location: sara_core/engine.py, lines 225-244
Vulnerability Type: Fail-open safety validation
Risk Level: High

Vulnerable Code:

python

for rule in self.rules:
    if rule.before in normalized_tools and rule.after in normalized_tools:
        before_idx = normalized_tools.index(rule.before)
        after_idx = normalized_tools.index(rule.after)

        if before_idx > after_idx:
            violations.append(
                {
                    "type": "order_violation",
                    "severity": rule.severity,
                    "message": f"Run '{rule.before}' before '{rule.after}'. {rule.reason}",
                    "before": rule.before,
                    "after": rule.after,
                }
            )

return violations

Technical Analysis

The auditor evaluates a rule only when both the protected action and its prerequisite are present. It does not generate a violation when a high-risk action is present but the corresponding prerequisite is entirely absent.

As a result, plans containing only actions such as delete, publish, or read_private_data are considered safe because there is no prerequisite action whose position can be compared. This contradicts the documented hard requirements for backup, preview, permission, and checks.

The validation therefore fails open in precisely the cases where a caller omits a required safeguard.

Attack Path

1. A caller constructs a plan containing a protected action, such as ["delete"].
2. The action is normalized to delete.
3. The backup -> delete rule is skipped because backup is not present.
4. No violation is added.
5. audit_trajectory returns is_safe: true and risk_level: low.
6. An agent relying on the audit result may proceed without creating a backup.

The same path applies to plans that omit checks, permission acquisition, or previews.

Impa

...[truncated 477 chars]

Remediation

View remediation

Remediation Suggestions

Treat a protected action with a missing prerequisite as a violation rather than as a safe plan.

For each rule:

1. Detect whether rule.after is present.
2. If rule.before is absent, emit a missing_prerequisite violation.
3. If both are present, verify that an appropriate prerequisite occurrence precedes each protected occurrence.
4. Fail closed when validation cannot determine whether prerequisites are satisfied.
5. Add automated tests for ["delete"], ["publish"], ["read_private_data"], and other missing-prerequisite cases.
6. Test repeated actions, including plans where the first protected action occurs before the first prerequisite.

T09 · Insecure Skill Coding Practices

Error

• Location: sara_core/engine.py:249

Finding

Global Priority Sorting Can Produce Unsafe Suggested Workflows

Content

View full analysis

Vulnerability Details

File Location: sara_core/engine.py, lines 249-256
Vulnerability Type: Unsafe workflow reordering
Risk Level: High

Vulnerable Code:

python

def _suggested_order(self, normalized_tools: list[str]) -> list[str]:
    indexed = list(enumerate(normalized_tools))

    def sort_key(item: tuple[int, str]) -> tuple[int, int]:
        idx, tool = item
        return (self.priority.get(tool, 50), idx)

    return [tool for _, tool in sorted(indexed, key=sort_key)]

Technical Analysis

When any violation is detected, the implementation globally sorts the complete workflow according to fixed action priorities. It does not limit changes to the violated relationship and does not model dependencies between unrelated steps.

Unknown tools receive a default priority of 50, while recognized operations can be moved before or after them based only on their action class. This can break valid data-flow, authorization, preparation, or cleanup dependencies that are not represented by the four hard-coded rules.

The resulting sequence is exposed as suggested_order, which implies that it is safer despite not having been semantically validated.

Attack Path

1. Construct a workflow containing one known reversed pair so that a violation is triggered.
2. Add dependency-sensitive or unknown actions whose required ordering is not represented in Sara's rules.
3. Sara globally sorts all actions by generic priority.
4. The unrelated actions move across their dependencies.
5. An agent follows suggested_order under the assumption that it is safe.
6. The reordered workflow performs an action before its real prerequisite or processes the wrong state.

Impact Assessment

This issue does not directly grant additional system privileges. It affects the integrity and safety of multi-tool workflows and can influence every action included in a generated suggestion.

Depending on the invoke ...[truncated 259 chars]

Remediation

View remediation

Remediation Suggestions

Replace global priority sorting with constraint-aware ordering:

1. Represent safety rules as directed ordering constraints.
2. Apply a stable topological sort that preserves the original relative order of unconstrained actions.
3. Move only actions required to resolve confirmed violations.
4. Support caller-supplied dependency constraints for actions outside the built-in rule set.
5. Re-audit the generated sequence before returning it.
6. If dependencies conflict or cannot be resolved safely, return no suggested order and require manual review.
7. Add tests involving unknown tools and independent preparation dependencies.

T07 · Tool Hijacking and Spoofing

Warning

• Location: scripts/run_audit.py:20

Finding

Bundled Auditor Module Can Be Shadowed Through Python Import Precedence

Content

View full analysis

Vulnerability Details

File Location: scripts/run_audit.py, lines 20-24
Vulnerability Type: Local module import hijacking
Risk Level: Medium

Vulnerable Code:

python

ROOT = find_project_root(Path(__file__).resolve())
if str(ROOT) not in sys.path:
    sys.path.append(str(ROOT))

from sara_core.engine import SaraAuditor  # noqa: E402

Technical Analysis

The trusted project root is appended to sys.path rather than placed before existing search paths. Python resolves imports using the first matching package in the search order.

If an attacker can place a malicious sara_core package in an earlier import location, Python can load that package instead of the bundled implementation. Importing the replacement package or its engine module can execute arbitrary top-level Python code and can return falsified audit decisions.

Exploitation requires influence over an earlier import location, such as the execution environment, an existing search-path directory, or another writable package location.

Attack Path

1. An attacker places a malicious package named sara_core in a directory that appears before the detected project root in sys.path.
2. The victim invokes scripts/run_audit.py.
3. The script appends the legitimate root without overriding earlier entries.
4. from sara_core.engine import SaraAuditor resolves to the attacker-controlled package.
5. Python executes the malicious package initialization or module code.
6. The replacement auditor may execute arbitrary code or report unsafe plans as safe.

Impact Assessment

Successful exploitation permits arbitrary Python code execution with the same operating-system privileges as the process invoking the audit script. It can also compromise all audit outputs produced by that invocation.

Potential effects include reading or modifying files accessible to the process, accessing inherited environment variables, invoking local p ...[truncated 158 chars]

Remediation

View remediation

Remediation Suggestions

Ensure that the bundled implementation is loaded from a trusted, verified path:

1. Insert the resolved project root at index zero rather than appending it.
2. Remove or reject conflicting sara_core modules already loaded from outside the project root.
3. Prefer explicit loading through importlib.util.spec_from_file_location using the resolved bundled file.
4. After import, verify that Path(module.__file__).resolve() is contained beneath the expected project root.
5. Run the script in an isolated environment with a controlled PYTHONPATH.
6. Ensure project and package directories are not writable by less-trusted users.

SkillSpector

Vulnerability Patterns

• Trigger Abuse: Overly Broad Trigger, Shadow Command Trigger, Keyword Baiting Trigger
• Prompt Injection: Instruction Override, Hidden Instructions, Exfiltration Commands
• Data Exfiltration: External Transmission, Env Variable Harvesting, File System Enumeration
• Privilege Escalation: Excessive Permissions, Sudo/Root Execution, Credential Access
• Supply Chain: Unpinned Dependencies, External Script Fetching, Obfuscated Code

Findings (1)

Vague Triggers

Low

• Category: Not specified by scanner
• Confidence: 87% confidence

Finding

The README describes Sara's activation conditions in broad, qualitative terms such as 'most useful when' and 'usually unnecessary,' without giving strict invocation criteria or precedence rules. In a multi-skill environment, ambiguous triggering can cause the guard to be skipped when needed or invoked inconsistently, weakening a safety control around destructive or externally visible actions.

Content

No source excerpt is available for this finding.