Assess, fix, keep it that way

EdgeReadyEdgeResolveEdgeAssure

For investors

EdgeSignalAll services
How it works Find your path Case studies Security About What we take on Book a 20-minute triage call
For procurement and security review

How we access your cloud, what we handle, and where the boundaries are.

InfraEdge is designed around least privilege, customer-controlled access and evidence minimisation. This page explains our access model, data boundaries, automation controls, retention and third-party processing so your security team can review the model directly.

  • Customer controlled
  • Least privilege
  • No standing admin
  • Evidence minimisation
  • Human approval
Access
01 / 9

Access stays on your side of the AWS boundary.

You create a scoped cross-account IAM role in the AWS accounts included in the engagement. InfraEdge assumes that role using temporary AWS STS credentials and an engagement-specific external ID.

  • No shared keys
  • Temporary STS credentials
  • Read-only
  • Named accounts
InfraEdge

AssumeRole

Temporary STS session · Unique External ID

Your AWS environment

Scoped InfraEdge IAM role

  • Custom read-only discovery policy
  • Named accounts only
  • Configuration metadata

AWS resource configuration

What exists, how it is configured, where engineering risk sits

  • Customer controlledYou create the role.

    The role exists in your AWS account and remains under your control.

  • Temporary credentialsNo long-lived AWS keys.

    InfraEdge uses AWS STS AssumeRole sessions rather than shared IAM user credentials.

  • Scoped accessNamed accounts only.

    You deploy the role only in the AWS accounts included in the engagement.

  • Read-onlyNo production changes.

    The discovery role cannot create, modify or delete AWS resources.

Customer controlled. Disable or remove the role at any time to prevent new InfraEdge sessions. Existing temporary STS sessions expire automatically according to their configured session duration.

Configuration plane

What InfraEdge can inspect

  • AWS resource configuration and metadata
  • IAM roles, policies and trust relationships
  • CloudTrail, logging and security configuration
  • Backup policies and recovery configuration
  • Infrastructure-as-Code and CI/CD configuration when separately scoped

Used to establish what exists, how it is configured and where engineering risk sits.

No production authority

What InfraEdge cannot do

  • Create, modify or delete AWS resources
  • Deploy applications or infrastructure
  • Access accounts where you have not deployed the role
  • Read application database contents
  • Call Secrets Manager GetSecretValue or SSM GetParameter APIs

The discovery policy does not grant Secrets Manager secret-value or SSM secure-value retrieval APIs.

Repository and CI/CD access is separately scoped and authorised where required. The AWS role does not grant GitHub, GitLab or Azure DevOps access.

View technical access model

Authentication

  • AWS STS AssumeRole
  • Unique External ID per engagement
  • No shared long-lived AWS access keys

Scope

  • Customer-owned IAM role
  • Accounts you choose to include in the engagement
  • Custom InfraEdge discovery policy

Session lifecycle

  • Temporary STS session
  • Customer can disable or remove the role
  • No new sessions after access is removed
  • Existing sessions expire at configured duration

Policy philosophy

  • Configuration and control-plane discovery only
  • Explicit API allow-list where practical
  • Explicit deny on secret-value retrieval
  • No write APIs

InfraEdge publishes a purpose-built discovery policy rather than relying on AWS-managed ReadOnlyAccess. Under the standard discovery role, secret-value retrieval APIs are denied (secretsmanager:GetSecretValue, ssm:GetParameter*, kms:Decrypt). Write APIs are not granted.

Data
02 / 9

Configuration evidence, not application data.

Collection starts from an allow-list of required evidence. InfraEdge defines what fields are needed for the assessment rather than collecting broadly and attempting to remove sensitive data afterwards.

AWS estate
Allow-listed collectors
Configuration evidenceNormalised assessment data

Collected where required

  • Resource configuration and metadata
  • IAM configuration and credential metadata
  • Logging, networking, backup and exposure configuration
  • IaC / CI configuration where repository access is separately authorised
  • Service-level cost and usage metadata where included in scope

Outside normal collection

  • Application database contents
  • S3 object contents
  • Secret or secure-parameter values
  • Application customer records
  • Environment or application data unrelated to the assessment
  • Accounts or repositories outside the agreed scope

Repository access is separately scoped. The AWS discovery role does not itself provide access to GitHub, GitLab or Azure DevOps.

Retention
03 / 9

Evidence has a lifecycle.

Different artefacts have different purposes. Retention should reflect that purpose rather than defaulting to keeping everything indefinitely.

  1. Collect
  2. Assess
  3. Report
  4. Retention window
  5. Delete / retain audit record
  • Raw cloud inventoryOwner: You
    30 days after reporting

    Minimise the most sensitive evidence we hold

  • Normalised assessment evidenceOwner: You
    Engagement + 90 days

    Re-run checks and preserve the assessed state

  • Findings and approvalsOwner: Joint
    6 years

    Maintain an auditable record of findings, advice and approvals

  • Final reportOwner: You
    Your choice

    An integrity hash can be retained rather than the report body

  • Policy packs, collectors and modulesOwner: InfraEdge
    Ongoing

    InfraEdge IP containing no customer data

Figures above are the published engagement retention schedule. Automated product TTLs and deletion-verification jobs are not what enforce them today — retention is applied as an engagement process.

Deletion workflow

Request / expiry → Delete → Record completion

Deletion is treated as a workflow with artefact categories, not only a storage setting.

Threat model
04 / 9

We design for failure modes, not just happy paths.

Preventive controls reduce risk. Detection describes how we know when those controls have not behaved as expected — stated only where the current platform supports it.

  • ThreatPrompt injection / untrusted customer content
    Prevent

    Deterministic checks run independently of any model-assisted analysis.

    Detect

    Deterministic findings remain recorded even when analysis is later added.

  • ThreatCross-customer access
    Prevent

    Engagement-scoped identity and storage boundaries for customer evidence.

    Detect

    Engagement activity is attributable to the engagement context in which it runs.

  • ThreatConfused-deputy AWS access
    Prevent

    Unique external ID on the customer trust policy, plus account assertion at collection time.

    Detect

    Collection aborts when the assumed role's account does not match the requested account.

  • ThreatUnsafe remediation
    Prevent

    Remediation proposes change plans; production apply remains a human-gated path.

    Detect

    Plan artefacts are hashed so an approval can be bound to a specific plan body.

  • ThreatSecrets entering evidence
    Prevent

    Discovery policy denies secret-value APIs; collectors project safe fields and redact known secret-bearing keys.

    Detect

    Known secret-bearing keys are scrubbed from evidence snapshots where redaction runs.

  • ThreatIncomplete deletion
    Prevent

    Deletion is treated as an engagement workflow with artefact categories, not only a storage toggle.

    Detect

    Completion is recorded against the engagement retention schedule.

CI/CD for this website uses short-lived GitHub OIDC federation. Broader operational MFA and monitoring controls are organisational practice rather than claims enforced by product code in this repository.

Communication
05 / 9

Automation cannot speak for InfraEdge without accountability.

Automated systems may draft or prepare customer-facing content, but final release remains attributable to a named person where the workflow uses automated communication.

  1. AI / automationDraft
  2. ReviewNamed human
  3. GateContent-bound approval
  4. ReleaseExternal send
  • Isolated sending authority. External sending permissions are restricted to dedicated workflows or services rather than being generally available.
  • Content-bound approval. Where automated release is used, approval is required against the draft being sent — changing the draft requires a new approval.
  • Named accountability. A human remains responsible for what InfraEdge communicates.

Outbound automated sending with cryptographic content binding is the designed control for customer-facing automation. It is not claimed as a generally available product feature on every engagement today.

Automation boundaries
06 / 9

Automation assists engineering. It does not hold authority.

We use automation for collection, deterministic checks, correlation, testing and drafting. Production authority and customer-facing release stay with people.

Automation can

  • Collect approved configuration evidence
  • Run deterministic checks
  • Correlate technical evidence
  • Prepare remediation plans
  • Run tests
  • Draft reports and communications

Human authority boundary

Human authority required

  • Production changes
  • Destructive actions
  • Material finding suppression
  • Final critical-risk or compliance judgement
  • Engagement scope changes
  • Customer-facing release
  • Approvals

EdgeResolve proposes remediations and records plan hashes. Applying changes to your production environment is not an automated path in the product.

Customer-hosted
07 / 9

Evidence can stay inside your cloud boundary.

For organisations that do not want infrastructure evidence stored in an InfraEdge-controlled environment, collection can be designed to run inside the customer’s own cloud account.

Standard model

  1. Customer AWS
  2. Scoped evidence
  3. InfraEdge-controlled processing

Customer-hosted model By engagement design

  1. Collector in your environment
  2. Customer-controlled storage
  3. Only agreed outputs cross the boundary

Customer-hosted collector

Where an engagement requires it, collection can be designed so evidence is written to storage you control. This is engagement architecture, not a self-serve product switch today.

No-model processing

Deterministic checks → engineering review

Assessments run on deterministic checks without requiring evidence to be sent to a model provider. Senior engineering review remains available without AI-assisted analysis.

Security reporting
08 / 9

Found a security issue?

Report it directly. We want to hear about problems affecting InfraEdge or customer information.

support@infraedge.org

  • Security reporting
  • Incident response
  • Customer notification

Security issues affecting InfraEdge or customer information are handled through our incident-response process and applicable contractual notification obligations.

This site
09 / 9

The marketing site follows the same minimisation principle.

The security principles on this page also apply to the site delivering it.

  • No advertising tracking. This site does not load advertising technology or behavioural tracking scripts.
  • Minimal external dependencies. Core assets, including fonts, are self-hosted.
  • Portable sample reports. Published sample reports are designed to render without contacting external services.

No analytics cookies are set by the current static site. If optional analytics are introduced later, that change will be reflected here and in the privacy notice.

Send this page to your security reviewer

If your review requires a control not covered here, tell us what your team needs to assess. We will answer directly — including when a requirement is not something InfraEdge can meet.

Book a 20-minute triage call See how we work