A Surfaces engagement

Surface Assessment

Start with one application domain—HR, finance, customer support, or another real setting—and one AI surface: a chatbot, agent, MCP integration, or AI workflow.

We follow that surface through the application to understand what it can access and affect, whether meaningful behaviour is observable, how relevant attacks manifest, and whether there is a credible path to detect and protect.

Whole surface

Follow the application, not only the prompt.

We examine the parts that can turn model behaviour into an application consequence:

  • intended business behaviour and consequential outcomes;
  • user and service identities, permissions, and delegated authority;
  • sensitive data, tools, services, and state-changing actions;
  • available telemetry and missing AI application-security observability;
  • the controls that detect, deny, constrain, or fail to affect the path; and
  • the authoritative downstream result used to decide what actually happened.

Two ways in

Start with uncertainty or start with the issue.

Start where you are. Stop when you know enough. Continue when there is a worthwhile path to detect and protect.

Explore

Explore a surface

You know the domain and the AI feature, but not where the meaningful risk or evidence gap sits. Begin by framing the surface and making the application path observable enough to decide what deserves testing.

Bring one surface

Respond

Bring an active issue

You have a known or suspected disclosure, action, control failure, or attack path. Establish the minimum safe context, reproduce what matters, and move quickly toward an evidence-backed response.

See the Active issue pathway

Movable boundary

The engagement moves only as far as it needs to.

  1. Frame

    Agree the application domain, selected surface, authority, meaningful behaviours, and safe evidence boundary.

  2. Observe

    Map the real application path and establish what can and cannot be seen in current telemetry.

  3. Exercise

    Run relevant, authorised attacks and trace attempted and completed effects through the system.

  4. Decide

    Stop with evidence and options, or explicitly agree that the next stage is worthwhile.

  5. Detect / Protect

    Improve telemetry, detection, or bounded controls at the layer that owns the authority, capability, or consequence.

  6. Prove

    Repeat equivalent tests and verify the authoritative downstream outcome after change.

Active issue pathway

When the question is already urgent.

Bring the known or suspected issue. We still establish authority, safe handling, and a reproducible boundary, but we do not make you repeat discovery work you have already done.

The first useful outcome may be a verified explanation, a missing observability signal, a bounded control change, or a retest that shows whether the consequential effect has stopped. The next step is agreed from the evidence, not assumed in advance.

Bring an active issue

Evidence before claims

A warning is not the same as prevention.

A model response, an alert, an enforcement decision, and a verified downstream result are different evidence states. The assessment keeps them separate.

Evidence state explorer

A warning, a block, and a verified outcome are not the same thing.

Select each state to compare what appeared in the interface with what happened in the application.

What the model showed

A response that sounds cautious is shown to the user.

What the application did

The overpowered service identity still completes the unsafe email action.

What this proves

The application is vulnerable. The message did not enforce the boundary.

What the model showed

A detector raises a warning around the same attempt.

What the application did

The downstream action remains possible because nothing enforces the warning.

What this proves

Detection is evidence, not prevention. The consequential path is still open.

What the model showed

The interface reports that this pinned attempt was stopped.

What the application did

An application control denies the action before it reaches the email service.

What this proves

This path was blocked. It does not establish universal protection.

What the model showed

The same meaningful attempt is repeated after the correction.

What the application did

Authoritative readback shows that no unsafe email side effect exists.

What this proves

The narrow correction held for the pinned scenario and produced the intended effect.

Required

A safe, authorised boundary.

We need an authorised target, a named owner, agreed test identities and data, explicit constraints, safe evidence handling, and access to the people who understand or can change the application.

Not this service

No universal assurance claim.

This is not compliance certification, unrestricted penetration testing, destructive testing, or proof that every prompt injection or future attack is blocked. Specialist work outside Viewyonder’s competence is identified rather than improvised.

Not ready to commit?

Try the self-assessment.

Use six questions to find a sensible starting point for one surface.

Choose the closest answer for one AI surface. Your answers stay in this page and disappear when you leave or reload it.

This is a starting-point check, not a maturity score. Completing it does not establish that the surface is secure.

1Can you name the surface, its application owner, and the business outcome it is meant to support?
2Do you know which sensitive data, tools, services, or consequential actions the surface can reach?
3Can you trace whose identity and authority are used at each step of the application path?
4Can you verify the authoritative downstream result, rather than relying only on the model response?
5Can you distinguish a warning that detects an attempt from a control that actually prevents the outcome?
6Do you have an authorised target, safe test identities and data, and an owner who can accept the constraints?
Discuss a Surface Assessment

Start with what you know

Describe one domain and one AI surface.

An ordinary-language description is enough. Do not include credentials, customer data, prompts, or confidential architecture details.

Start the assessment conversation