> ## Documentation Index
> Fetch the complete documentation index at: https://docs.parmanasystems.com/llms.txt
> Use this file to discover all available pages before exploring further.

# Talk and demo videos

> The outline of a 20 minute talk on Parmana, and scripts for four short demo videos you can follow step by step against the public sandbox.

## The talk

A 20 minute talk for engineers, security teams and auditors: what an AI agent may do, and proof of what it did.
Thirteen slides, each with speaker notes.

| # | Slide | The point |
| - | - | - |
| 1 | What an AI agent may do, and proof of what it did | The subject |
| 2 | An agent that can act turns a model error into an action | Replit and Amazon Q, 2025: the credentials the agent held decided what it could do |
| 3 | Existing controls answer narrower questions | IAM, API gateways and guardrails, and the question none of them answers |
| 4 | Every action takes the same path | Propose, policy, approve, release, record |
| 5 | A person approves one action, not a role | Bound to action, resource and amount; signed; single use; expiring |
| 6 | One place releases actions, and it checks again | The gateway re-verifies and holds the credentials |
| 7 | Evidence you can check without trusting us | Signed records of actions and refusals, verified offline; change one field and it fails |
| 8 | The agent is assumed hostile; the assumptions are written down | Attackers defended against, and the seven assumptions |
| 9 | 16 attacks you can run yourself | `npm run evaluate` |
| 10 | Mutation testing of the security critical code | 83.6% to 96.0% mutation score |
| 11 | Found, fixed, and published | G-87, G-88, G-89, G-91, and advisory GHSA-hp43-9p54-wqp9 |
| 12 | What Parmana does not do | No text inspection, only routed actions, approval granularity, people |
| 13 | Bound what an agent can make happen | Where to check everything |

The background for each slide is in the [technical paper](/evaluation/paper),
[How Parmana compares](/how-parmana-compares), the [case studies](/evaluation/case-studies) and
[Limitations](/security/limitations). To give this talk, write to [founder@parmanasystems.com](mailto:founder@parmanasystems.com).

<Card title="Download the slides (PDF)" icon="file-pdf" href="https://github.com/pavancharak/parmana/raw/main/docs/paper/parmana-talk-slides.pdf">
  All 13 slides, 16:9.
</Card>

## Demo videos

Four short videos. Each script below is the exact sequence to follow, so you can also run it yourself. Every step
uses the [public sandbox](/playground) and its published demo key, so nothing real is acted on. Send only demo text:
everything sent to the sandbox is visible to every visitor.

### 1. Parmana in 90 seconds

| Time | On screen | Say |
| - | - | - |
| 0:00 | The docs home page | AI agents now take real actions: refunds, merges, posts. Parmana decides whether each one may run, and records what happened. |
| 0:15 | The pipeline diagram on [How Parmana thinks](/how-parmana-thinks) | Every action goes through a policy, a person's signed approval, and a gateway that holds the credentials the agent never gets. |
| 0:35 | The [Playground](/playground) cURL script, step 3: a request with no approval | Here an agent asks for an action with no approval. Refused, and the refusal is signed. |
| 0:50 | Steps 4 and 5: get a demo approval, send again | With a signed approval for this exact target, it is released, and a signed record comes back. |
| 1:05 | Step 7: the same approval again | The approval was single use. Sending it twice is refused. |
| 1:15 | [Verify in browser](/verification/verify-in-browser) | Anyone can check the record offline with only the public key. Links are below. |

### 2. The whole flow against the sandbox, about 3 minutes

1. Open a terminal. Show the two `export` lines from the [Playground](/playground) cURL tab. Say: this is a published
   demo key; it can only call `sandbox:receipt`.
2. Run step 1, `GET /callers/me`. Point at `sandbox-visitor` and its one capability.
3. Run step 2, the policy in effect. Point at the approval signal: this policy approves only with a signed approval
   for the request's target.
4. Run step 3 with no approval. Point at the refusal and its reason. Say: no approval, no action, and the refusal
   is recorded.
5. Run step 4, `POST /sandbox/approvals`. Say: in production a person signs this; the sandbox signs one for the demo.
   Point at its expiry, 5 minutes.
6. Run step 5 with the approval. Allow 10 to 15 seconds. Point at the receipt from the release endpoint and the
   signed Execution Trust Record.
7. Run step 6, the offline check. Point at `valid: true`.
8. Run step 7, the same approval again. Point at the refusal: the approval was spent.

### 3. Verify a record yourself, about 2 minutes

1. Open [Verify in browser](/verification/verify-in-browser). Say: nothing is sent to a server; the check runs in
   this page.
2. **Load the example**, then **Verify**: valid.
3. **Load the example, changed**: the amount went from 100 to 100000. **Verify**: the hash no longer matches. Say:
   change any signed field and verification fails.
4. Paste the record from video 2, click **Use the sandbox key**, **Verify**: valid.
5. Close with what this proves: the record is unchanged and was signed by the key holder. It does not prove the key
   holder was honest; see [Limitations](/security/limitations).

### 4. Attack it yourself, about 3 minutes

On a local copy of the repository (Node 24, `npm ci`, `npm run build`):

1. Show the scenario list in `evaluations/scenarios.json`. Say: 16 attacks, each passes only when the attack is
   refused or detected.
2. Run `npm run evaluate -- EV-04`: act without a person's signed approval, the prompt injection case. Show the
   result.
3. Run `npm run evaluate -- EV-01`: replay a used authorization. Show the result.
4. Run `npm run evaluate -- EV-14`: alter a signed record after the fact. Show the result.
5. Run `npm run evaluate` for all 16. Point to the [Security challenge](https://github.com/pavancharak/parmana/blob/main/SECURITY-CHALLENGE.md):
   if you find a way through, report it privately.

Recording notes: use a terminal font of at least 18 points, show one command at a time, and keep the demo key on
screen only where the docs already publish it. Never show a real API key, `.env` file or signing key.


This documentation is built and hosted on [Mintlify](https://mintlify.com), a developer documentation platform.