AI-Assisted Vulnerability Research: When Offense Meets Automation

Graph-Powered OSINT: From Data to Investigation with Agentic AI

Open-source intelligence has always been a graph problem: entities, relationships, provenance. The 2026 shift is that generative and agentic AI can do the investigation part too. This article reviews the emerging OSINT+graph research: entity resolution, temporal threat intelligence, agentic collection, and the hallucination risk that makes graphs essential.

Two August 2026 announcements crystallised a shift in offensive security: Zhipu's GLM-5.3 with "emergent cyber capabilities" and OpenAI's GPT-5.6-Cyber with "reduced safeguards for exploit development." Both are frontier coding models repurposed for security research — and both change the economics of vulnerability discovery.

The question for defensive teams is not whether AI-assisted offense is coming. It is here. The question is how to adapt: which guardrails matter, which attack patterns scale with AI, and how to map an attack surface that is now being probed by models that never sleep.

What GLM-5.3 and GPT-5.6-Cyber Actually Do

Both models are coding models first. Their "cyber capabilities" are emergent — they come from the same reasoning, code comprehension, and pattern-matching that makes them good at software engineering. The security-relevant capabilities fall into four buckets:

The key insight: these capabilities are dual-use. The same model that generates an exploit can audit the patch. The same pattern recognition that finds vulnerabilities can prioritise remediation.

The Guardrails That Actually Matter

1. Sandboxed Execution

Never run AI-generated exploit code on production infrastructure. Period.

# Safe pattern: isolated sandbox for AI-generated PoCs
import subprocess
import tempfile

def run_ai_generated_poc(poc_code: str, target: str):
    with tempfile.NamedTemporaryFile(suffix=".py", mode="w", delete=False) as f:
        f.write(poc_code)
        f.flush()

    result = subprocess.run(
        ["python3", f.name],
        capture_output=True,
        text=True,
        timeout=30,
        env={
            "PATH": "/usr/bin:/bin",
            "HOME": "/tmp",
            "TARGET": target,  # Only pass the target, not credentials
        },
        # Run in a container or namespace
        cwd="/tmp",
    )
    return result.stdout, result.stderr

2. Output Validation

AI models hallucinate. Every generated exploit must be validated:

def validate_exploit(poc_output: str, expected_cwe: str) -> bool:
    """Validate that a PoC actually demonstrates the vulnerability"""
    checks = [
        ("crash" in poc_output.lower(), "No crash evidence"),
        ("exploit" in poc_output.lower(), "No exploit confirmation"),
        (expected_cwe.lower() in poc_output.lower(), f"No {expected_cwe} reference"),
    ]
    return all(check[0] for check in checks)

3. Rate Limiting and Audit Logging

# ai-security-gateway.yml
rate_limits:
  exploit_generation: 10/hour
  vulnerability_scan: 100/hour
  code_analysis: 1000/hour

audit_log:
  enabled: true
  destination: /var/log/ai-security-audit.jsonl
  fields:
    - timestamp
    - user
    - model
    - prompt_hash
    - output_hash
    - target_system
    - action_class

Attack Surface Mapping with Graphs

The real defensive opportunity is not in generating exploits — it is in mapping the attack surface before attackers do. This is where graph databases shine.

The Attack Surface Graph

                    ┌──────────┐
                    │ Internet │
                    └────┬─────┘
                         │
                    ┌────▼─────┐
                    │  Firewall│
                    └────┬─────┘
                         │
              ┌──────────┼──────────┐
              │          │          │
         ┌────▼───┐ ┌───▼────┐ ┌───▼────┐
         │Web App │ │ API GW │ │  VPN   │
         └────┬───┘ └───┬────┘ └───┬────┘
              │         │          │
         ┌────▼───┐ ┌───▼────┐ ┌───▼────┐
         │Postgres│ │ Redis  │ │  LDAP  │
         └────────┘ └────────┘ └────────┘

Each node is an asset. Each edge is a trust relationship. Vulnerabilities are properties on nodes or edges. The attack surface is the reachable subgraph from any entry point.

Querying the Attack Surface

// Find all paths from internet-facing services to databases
MATCH path = (entry:Service {exposed: true})-[:TRUSTS*1..5]->(db:Database {sensitive: true})
WHERE ALL(r IN relationships(path) WHERE r.protocol IN ['tcp', 'http', 'grpc'])
RETURN path, length(path) AS hops
ORDER BY hops ASC

// Find services with known vulnerabilities reachable from the internet
MATCH (s:Service)-[:HAS_VULNERABILITY]->(v:Vulnerability {severity: 'critical'})
WHERE s.exposed = true
RETURN s.name, v.cve, v.severity, v.description

// Find trust paths that bypass network segmentation
MATCH path = (a:Service)-[:TRUSTS*1..10]->(b:Service)
WHERE NOT EXISTS {
  MATCH (a)-[:IN_ZONE]->(z1:Zone), (b)-[:IN_ZONE]->(z2:Zone)
  WHERE z1 = z2
}
RETURN path

AI-Augmented Attack Surface Discovery

The combination of AI and graph-based attack surface mapping is where the defensive advantage lies:

1. AI reads code to identify trust relationships the graph is missing
2. AI generates Cypher queries to explore attack paths
3. AI validates findings against the graph (is this path actually reachable?)
4. The graph provides ground truth that AI hallucinations cannot fake

class AIAttackSurfaceMapper:
    def __init__(self, graph, llm):
        self.graph = graph  # Neo4j with attack surface data
        self.llm = llm      # GLM-5.3 or GPT-5.6-Cyber

    def discover_trust_relationships(self, codebase):
        """AI reads code to find trust relationships the graph is missing"""
        prompt = f"""
        Analyse this codebase for trust relationships:
        - Service-to-service authentication
        - Database connections
        - API key usage
        - Network calls

        Return as JSON: {{"source": "...", "target": "...", "protocol": "...", "auth": "..."}}

        Codebase: {codebase[:5000]}...
        """
        relationships = self.llm.generate(prompt)
        return self._validate_and_add(relationships)

    def generate_attack_path_queries(self, target):
        """AI generates Cypher queries to find attack paths to a target"""
        prompt = f"""
        Given a Neo4j attack surface graph with nodes (Service, Database, Vulnerability)
        and edges (TRUSTS, HAS_VULNERABILITY, EXPOSED_TO),
        generate Cypher queries to find attack paths to: {target}

        Consider: lateral movement, privilege escalation, vulnerability chaining.
        """
        queries = self.llm.generate(prompt)
        return self._execute_and_validate(queries)

    def _validate_and_add(self, relationships):
        """Validate AI-generated trust relationships before adding to graph."""
        ...

    def _execute_and_validate(self, queries):
        """Execute Cypher queries and validate results against the graph."""
        ...

    def validate_findings(self, finding):
        """Validate AI findings against the graph (ground truth)"""
        cypher = """
        MATCH path = (s:Service {name: $source})
                    -[:TRUSTS*1..5]->
                    (t:Service {name: $target})
        RETURN path
        """
        result = self.graph.run(cypher, source=finding.source, target=finding.target)
        return len(result) > 0  # Only accept findings the graph confirms

The Real Threat Model

AI-assisted vulnerability research does not change the fundamental threat model. It changes the scale and speed:

The defensive implication is clear: the patch-before-exploit window is shrinking. Organisations that rely on manual processes will fall behind.

Practical Recommendations

For Offensive Teams

1. Use AI for reconnaissance, not execution. AI is excellent at mapping codebases and identifying patterns. It is less reliable at generating working exploits.
2. Validate every finding. AI hallucinates. Use graph-based ground truth to filter false positives.
3. Log everything. Every AI-generated query, every finding, every exploit attempt. Audit trails are non-negotiable.

For Defensive Teams

1. Map your attack surface as a graph. Before AI attackers do it for you.
2. Automate vulnerability scanning with AI. Use coding models for SAST, not just exploit generation.
3. Shrink the attack surface. Every trust relationship is a potential attack path. Remove unnecessary ones.
4. Monitor for AI-assisted probing. Unusual query patterns, rapid vulnerability scanning, coordinated exploit attempts.

For Platform Teams

1. Implement AI security gateways. Rate limits, audit logging, output validation.
2. Sandbox AI-generated code. Never run on production.
3. Use AI for defence too. The same models that can find vulnerabilities can audit patches.

What's Next

The offensive-defensive AI arms race is accelerating. Three developments to watch:

1. Model-specific safety training. GLM-5.3 and GPT-5.6-Cyber have reduced safeguards. Expect more models with "cyber" variants.
2. Graph-native attack surface management. Tools that map attack surfaces as graphs (BloodHound, Maltego, custom Neo4j) will integrate with AI for continuous discovery.
3. Regulatory response. The EU AI Act and NIS2 Directive will impose requirements on AI-assisted security tools. Start tracking compliance now.

The organisations that win this race will be those that use AI for defence as aggressively as attackers use it for offence. The technology is dual-use. The advantage goes to whoever deploys it first and most thoroughly.

Further Reading

• GLM-5.3: Zhipu AI announcement
• GPT-5.6-Cyber: OpenAI security research
• BloodHound: Graph-based attack path discovery
• OWASP AI Security Guide: AI-specific threat patterns
• MITRE ATT&CK: Adversarial tactics mapped to graph relationships