TECHNICAL OVERVIEW

Evidence you can trace.
Boundaries you can review.

A reference architecture for technical evaluation: identity and resource relationships, data contracts, integration handling, and operational requirements. Confirm the implemented behavior during product evaluation.

Architecture reference, not an API contractThis page describes design considerations and illustrative schemas. It does not claim that skur.ai currently exposes these endpoints or implements the controls below. Deployment, security controls, and available functionality require confirmation.

01 / COLLECTION

Collect scoped evidence

Inventory resource metadata, identity grants, configuration observations, and ownership references within approved boundaries. Separate discovery access from any permission to make changes.

Keep source IDs and observation timestamps.
Record account, project, region, and service scope.
Track collection errors and unassessed resources.
Exclude secrets and payload content unless explicitly required and authorized.

02 / NORMALIZATION

Model relationships

Represent resources as entities and access or deployment relationships as edges. Preserve source provenance so an investigator can validate how a conclusion was formed.

Entity types: workload, identity, repository, dataset.
Edges: deployed-from, assumes-role, can-read, owned-by.
Preserve policy conditions and uncertainty.
Distinguish observed facts from inferred relationships.

03 / ANALYSIS

Evaluate a plausible path

Use reachability, effective permissions, and data context to frame an investigation. A path is not proof of exploitation; validate the underlying conditions and compensating controls.

Network exposure and application authentication.
Role trust and resource-policy conditions.
Data classification and service importance.
Evidence freshness and assessment coverage.

04 / DELIVERY

Route a reviewable action

Package the evidence, owner, proposed next step, and validation criteria. Avoid sending sensitive raw data to notification channels or issue trackers.

Use stable finding and resource references.
Deduplicate repeated events or work items.
Separate notification from execution approval.
Recheck evidence after a change is deployed.

ILLUSTRATIVE DATA MODEL

Keep context
attached to the finding.

This sample JSON demonstrates useful fields for a handoff. It is not a documented skur.ai API response or an executable request.

{
  "finding_id": "example-exp-001",
  "environment": "production-example",
  "status": "requires_validation",
  "observed_at": "2026-10-26T12:00:00Z",
  "source": {
    "system": "cloud-inventory-example",
    "scope": "approved-account"
  },
  "path": [
    {
      "entity": "checkout-api",
      "relationship": "assumes-role"
    },
    {
      "entity": "application-role",
      "relationship": "can-read"
    },
    {
      "entity": "customer-exports",
      "classification": "sensitive"
    }
  ],
  "owner": {
    "team": "application-platform"
  },
  "next_step": "Review required storage access",
  "validation": "Confirm unintended read access is removed"
}

Why these fields matter

Provenance: Source, scope, and observation time let reviewers assess evidence freshness.
Relationships: The path explains how assets and permissions connect, rather than listing isolated alerts.
Ownership: A named team helps route the investigation to someone who can act.
Validation: A clear success condition distinguishes a completed task from a verified change.

INTEGRATION ENGINEERING

Design for delivery.
Plan for failure.

Events & webhooks

Validate sender authenticity and message integrity using the provider’s supported mechanism. Record delivery identifiers and handle duplicate or delayed events safely.

GitHub recommends webhook secrets and prompt delivery acknowledgement. See GitHub webhook guidance ↗.

APIs & work items

Agree the authentication method, allowed operations, field mappings, pagination, and rate-limit behavior. A retry must not silently create duplicate tickets.

Review the provider contract, such as the Jira Cloud REST API ↗, before choosing permissions or write actions.

Cloud access review

Validate proposed permissions, explicit denies, conditions, and cross-account trust. Review the exact policy against the evidence scope you have approved.

AWS provides policy checks through IAM Access Analyzer policy validation ↗. These checks complement an environment-specific review.

TECHNICAL EVALUATION CHECKLIST

Questions worth
answering before rollout.

Requirements to confirm during architecture and security review
Area	What to establish	Evidence to request
Deployment	Hosting model, regions, tenant boundaries, and network paths	Deployment diagram and data-flow inventory
Authentication	Supported sign-in methods, service identities, and session controls	Authentication design and permission matrix
Data protection	Encryption, key handling, retention, deletion, and backup scope	Data-handling documentation and operational procedures
Authorization	Roles, tenant separation, read/write boundaries, and approval steps	Role definitions and scoped access policies
Auditability	Event provenance, access logs, change records, and export options	Example audit records and retention settings
Reliability	Collection gaps, rate limits, retries, and delivery failure handling	Monitoring model, recovery procedure, and ownership
Response actions	Human approval, rollback, verification, and emergency revocation	Runbooks and change-management requirements

Bring your technical requirements.

Review source access, data handling, and workflow boundaries before implementation.

Plan a technical discussion ↗

Evidence you can trace.Boundaries you can review.