Before and after AI Application Security testing: one HR chatbot

An HR chatbot can look safe while the application around it still has too much authority.

In this synthetic example, Joe is allowed to use an HR chatbot for his own information. The chatbot can also reach HR application functions through a service identity. That service identity is the important boundary: if it has more authority than Joe, a polite refusal from the model is not evidence that the application is safe.

The question is not only what the model said. It is what the application tried, what its controls enforced, and what happened in the authoritative downstream system.

The supported claim

In a synthetic HR chatbot demonstration, the same attempt is shown as a vulnerable service-identity baseline, detected without prevention, optionally blocked, and retested with authoritative readback showing no unsafe email side effect.

1. Vulnerable service-identity baseline

The first run uses the chatbot’s more powerful service identity. The request crosses Joe’s intended user boundary, the application reaches data outside that boundary, and an unsafe email side effect is visible in the authoritative readback.

• Intent: Joe should be limited to his own permitted HR information.
• Attempt: The AI surface tries to use the application’s delegated authority outside that boundary.
• Enforcement: The existing application path allows the service identity to continue.
• Effect: The downstream system records the unsafe email side effect.

2. Detected without prevention

The second state shows why a warning is not the same as a control. The attempt is detected, but detection alone does not stop the application path.

• Intent: The same user boundary still applies.
• Attempt: The same meaningful path is exercised.
• Enforcement: A detection signal is raised, but prevention is not enabled.
• Effect: The downstream effect remains possible, so the application is not fixed.

3. Optionally blocked

The third state adds Runtime as one optional enforcement example. Runtime is not required for the assessment or for remediation: the owning correction could instead live in identity, authorization, tool permissions, application code, or another suitable control.

• Intent: Preserve the allowed HR use while denying the cross-user action.
• Attempt: Repeat the same meaningful path.
• Enforcement: The optional control blocks this pinned attempt.
• Effect: The blocked path does not create the unsafe email side effect.

4. Retested with authoritative readback

A block message is not the end of the test. The important path is repeated and the downstream system is checked directly.

• Intent: Confirm the narrow correction without claiming universal safety.
• Attempt: Repeat the pinned source-and-target scenario.
• Enforcement: The responsible control holds for this rerun.
• Effect: Authoritative readback shows no unsafe email side effect.

What the product team learns

The useful result is an owning control and a repeatable test. The team can distinguish a model response from an application result, identify why the service identity created excessive authority, make a narrow correction, and verify the consequential effect rather than trusting a banner or detector score.

Evidence status and limitations

This is a bounded account of one pinned synthetic source-and-target scenario. It does not prove that every prompt injection is blocked. It does not establish detector performance or universal safety. Runtime is optional.

This example does not replace infrastructure testing, a conventional penetration test, compliance work, or specialist security review. Planned comparisons with other tools provide no findings until those experiments have run. No raw injection strings, reusable exploit bodies, secrets, private-repository material, or real personal data are published here.

Apply the method to your product

The AI Application Security Assessment examines the identities, data, tools, controls, and downstream effects around one authorized AI surface, then helps the product team correct and retest meaningful paths.

Describe one AI feature in ordinary language. You do not need to send prompts, credentials, customer data, or confidential architecture details.