Define Cross-Surface Correlation Model for OpenPAKT Findings

[meisterware-admin]

Overview

Define a cross-surface correlation model for OpenPAKT findings.

Modern AI agent systems often span multiple execution surfaces, including:

• repository configuration files
• agent prompt definitions
• orchestration workflows
• tool invocation configurations
• CI pipelines
• runtime execution environments

Security risks may emerge across these surfaces rather than within a single artifact.

This proposal introduces a model that allows OpenPAKT findings to reference and correlate multiple related components across different surfaces of an AI agent system.

The objective is to enable scanners and analysis tools to represent multi-surface security relationships within OpenPAKT reports.

---

Motivation

AI agent security risks frequently arise from interactions between components, rather than from isolated configuration issues.

Examples include:

• a prompt template referencing a tool that has excessive permissions
• a CI workflow injecting untrusted input into an agent prompt
• an orchestration workflow passing sensitive data between agents
• a repository configuration enabling unsafe tool execution in CI

In these cases, the security issue is not confined to a single file or component.

Without a correlation model, scanners must either:

• emit multiple disconnected findings, or
• oversimplify the issue into a single component reference

Both approaches reduce clarity and make it difficult for security tools and CI dashboards to understand the full context of the risk.

A cross-surface correlation model would allow OpenPAKT to represent findings that span:

• multiple files
• multiple agent components
• multiple execution surfaces

This capability becomes increasingly important as AI agent ecosystems grow more complex and distributed.

---

Proposed Approach

Introduce a mechanism within OpenPAKT findings that allows related components across different surfaces to be correlated.

The model may include:

• a primary component associated with the finding
• a list of related components or surfaces
• contextual metadata describing how the components interact

Example conceptual structure:

finding:
  id: OPKT-2026-0101
  type: tool_abuse_privilege_escalation
  severity: high
  component: workflow.agent_step
  related_components:
    - type: prompt
      path: prompts/review_prompt.txt
    - type: tool
      name: shell

Possible correlation attributes may include:

Attribute	Description
component	Primary location of the finding
related_components	Additional surfaces involved in the risk
interaction_type	Nature of the relationship (optional)
context	Optional explanatory metadata

Example interaction types:

• prompt_to_tool
• workflow_to_agent
• agent_to_agent
• agent_to_external_service

This model should remain minimal and implementation-agnostic while allowing scanners to capture important security relationships.

---

Alternatives Considered

Single-component findings only

OpenPAKT could restrict findings to a single component location.

However, this would make it difficult to represent complex security risks involving multiple interacting components.

---

Scanner-specific correlation metadata

Scanners could include custom metadata to represent cross-surface relationships.

This approach risks fragmentation and inconsistent interpretations across tools.

Providing a standardized model improves interoperability.

---

External correlation engines

Another option would be to perform correlation only in external tooling or dashboards.

While possible, representing the correlation directly in OpenPAKT findings preserves context and portability.

---

Risks and Trade-offs

Increased specification complexity

Introducing correlation concepts may slightly increase the complexity of the OpenPAKT finding model.

This risk can be mitigated by keeping the model minimal and optional.

---

Implementation burden for scanners

Scanner implementations may need to identify relationships between artifacts.

However, correlation support can be optional and introduced gradually by tools.

---

Potential for inconsistent correlation usage

If the model is too flexible, tools may use it inconsistently.

Providing clear guidance and examples can mitigate this risk.

---

Open Questions

• Should correlation be represented directly within the finding structure, or as a separate top-level structure?
• Should the correlation model define standard interaction types?
• Should correlation identifiers allow linking multiple findings together?
• Should correlation metadata support multi-agent systems in future milestones?

---

Examples

Example OpenPAKT finding showing cross-surface correlation:

{
  "id": "OPKT-2026-0102",
  "type": "prompt_injection",
  "severity": "high",
  "component": "workflow.agent_prompt",
  "related_components": [
    {
      "type": "input_source",
      "path": "ci/pull_request_event"
    },
    {
      "type": "prompt_template",
      "path": "prompts/review_prompt.txt"
    }
  ],
  "description": "Untrusted CI input is inserted directly into the agent prompt without validation."
}

In this example, the finding spans:

• a CI workflow surface
• a prompt template surface
• the agent execution context

---

Next Steps

If this proposal gains support:

1. Define a minimal correlation model for OpenPAKT findings.
2. Document correlation field semantics.
3. Provide normative and non-normative examples.
4. Evaluate compatibility with SARIF and other reporting ecosystems.
5. Prototype correlation support in the Detektor scanner.

---

Architectural note

This issue is one of the most important in the OpenPAKT roadmap.

It lays the groundwork for:

• multi-agent security modeling (v0.3 milestone)
• workflow-level risk analysis
• cross-agent and cross-tool security correlation