# Team Security

The team **Security** page lives under **iKASecure** in the top bar. It is scoped to a team and groups code findings, AI endpoint findings, hardening controls, and the workspace audit log. Available tabs depend on workspace entitlements and, for the audit log, the signed-in user's workspace role.

## Open the security page

1. Select **iKASecure** in the top bar. It opens the last team you used, or your first team.
2. Select the required team under **Your teams** in the left sidebar. To see every team at once, select **All teams** above that list.
3. Start on **OWASP Top 10** to review code-security findings.
4. Open **Non-OWASP Controls** to review hardening controls when your plan includes the `security` entitlement.
5. Open **OWASP LLM Top 10** to review AI endpoint findings when your plan includes `aiRedTeam`. On a plan without it (Pro), **iKASecure → Overview**, **All teams** and **Applications** show the note "AI findings need the Pro+ plan" and count no AI findings; they do not open the upgrade popup.
6. Open **Audit Log** when the workspace has the `auditLog` entitlement and your role is **Owner** or **Admin**.

Tabs hidden by an entitlement or role cannot be opened from this page. The server enforces these checks as well as the page, so the visible navigation is not the security boundary.

![Security page navigation showing the OWASP Top 10 view](/docs/images/security/team-security-tabs.webp)

## Team tabs on Overview, All teams and Applications

**Overview**, **All teams** and **Applications** show the same row of team tabs: **All teams**, then one tab for each of your teams. Select a tab to see only that team's findings, severity counts, scans, rules and applications.

- The team stays in the address (for example `?team=IKA`), so a reload, a shared link, and the Back and Forward buttons keep it.
- The team carries across pages: **See all findings** on Overview, the **Overview**, **All teams** and **Applications** links in the sidebar, and **Run a scan**, which starts on that team.
- A team under **Your teams** opens that team's **Overview** tab. Its own page (OWASP groups, controls, audit log) is linked from there; that page has no dependency findings, so the tab is the count to trust.
- **Run a scan** publishes to the tab's team. On **All teams**, pick a team first.
- With only one team you see no tab row. A team you are not in, or an unknown team in the address, opens **All teams**.

## Run a scan

**Run a scan** opens one panel. An agent does the work: it fetches the scanners from iKanban, maps your folders to the team's applications, and publishes. You download nothing and type no command.

1. Pick **What to scan**: **Everything**, **Code**, **AI endpoints**, **Dependencies** or **Imported report**. Code and Dependencies are the same scan run.
2. Pick the **Team** the findings go to.
3. Select **Send to my runner** to start a session on your laptop's iKanban runner in the repository shown, with the agent shown (Claude, Copilot or Gemini). Or select **Copy prompt** and paste it into any coding agent opened in the repository.
4. The agent replies with one list: findings per severity, what it filed, which folders it mapped to which application, and what it skipped and why.

The prompt is the same text as `.iKanban/prompts/security-scan.md` and the `ikanban-security-scan` skill in the laptop kit. What decides whether a part runs:

| Part | Runs when | Otherwise the agent says |
|---|---|---|
| Code and dependencies | the team's plan has Security | the 402 answer: the plan lacks it |
| Dependency findings | a folder matches an application from `--list-apps` | which folders stayed in the report only; it asks only when two folders fit one application |
| A language's dependency check | its auditor (cargo-audit, pnpm or npm, pip-audit) is installed | SKIPPED, with the install command; nothing closes in that application |
| AI endpoints | the code has a chat endpoint, `OPENAI_API_KEY` is set in the agent's shell, the plan has AI findings (Pro+), Node.js is installed | one line naming which is missing |
| Imported report | the repository holds a SARIF or JSON or Markdown report from another scanner, up to 1 MB; secret scanners' reports (gitleaks, trufflehog, detect-secrets, semgrep secrets rules) are never filed | "No other scanner reports found", and each skipped file |
| Send to my runner | the runner is online, and a repository is linked | the session waits as Queued while iKanban starts the runner |

- **Copy prompt** reads the iKanban key from `.iKanban/settings-local.json` (laptop setup writes it). The key never appears in the prompt.
- The prompt names this iKanban server and the team you picked. A repository's own settings file cannot send the key anywhere else: an address other than api.i-kanban.com or dev-api.i-kanban.com stops the scan.
- Every filed report, from any scanner or from **File the report**, is cleaned by iKanban before it is stored: a secret-looking value keeps its first 4 characters, and a home folder becomes `~`.
- On the runner, a scan sent with **Send to my runner** downloads iKanban's own copy of each scanner and uploads its reports without asking, whatever **Agent settings → Runners → Risky actions** says. Only those calls to iKanban are allowed: every other network call still follows Risky actions, and the panel shows that rule. Gemini follows its own allow and deny rules instead. The runner needs iKanban desktop app 0.1.8 or newer for this; an older runner asks before each download and upload.
- For AI endpoints the agent writes `aiscan.toml` at the repository root, and reuses it on the next scan.
- **Run it yourself** (closed at first) keeps the manual way: the scanner download, the commands, and **File the report** for an imported report.

## Findings and controls

The OWASP Top 10 view groups findings by category; expand a category to inspect finding titles, locations, severity, and status. The Non-OWASP Controls view groups controls by domain; expand a control to inspect its threat/goal and source. For a missing control, **+ Task** creates a remediation task in the team's default project. These views are not a live scan of the repository: the page presents findings and control data published to iKanban.

For a local code scan, select **Scanner** to download the standalone repository scanner. Run it against your own repository from your machine. The scanner can publish results back to this page when run with `--publish`. It sends your API key only to iKanban's API (https://api.i-kanban.com, https://dev-api.i-kanban.com, or a server on your own machine) and never follows a redirect with it; any other `--base-url` stops the scanner before it sends anything. With `--publish` it files the report under **Scans**, and each committed secret (A07) and risky file permission (A05) as a finding on this page. Dependency findings are filed only for an application the team has: run `--list-apps` to see the names, then add `--app FOLDER=NAME` for each folder that holds one (for example `--app vibe-backend=backend`). Without `--app`, dependency findings stay in the report and reach no count. A rescan closes what it no longer finds, only for the same repository and, with `--app`, the same application. It files what is new and re-opens a finding marked fixed that it finds again. The scanner prints how many closed and re-opened. False positive and accepted findings never change, and a rescan never files the same flaw again as a new open finding. For a dependency, the same flaw means the same package and the same CVE id; a verdict on a finding with no CVE id does not hide a later one. A closed finding's fix task stays as it is, like **Mark fixed**. A dependency scan with a skipped auditor closes nothing in that application. Findings filed by a scanner older than 1.2.0 close only after a rescan reports them once. New numbers show when an agent's scan session ends, and on the next page visit or tab focus. A dependency upload names its team, and an application of another team is refused. On **iKASecure → Applications**, each application row shows its open and total findings: a dependency finding under its application, an AI finding under its endpoint, and a code finding under the team's **Code scans** row, because code findings do not name a repository. The rows of each kind add up to that kind's count on **iKASecure → Overview**.

For AI endpoint testing, select **AI scanner** from the **OWASP LLM Top 10** view. It runs from your machine against your own AI endpoints and covers prompt injection, data disclosure, and excessive agency. Results can be published with `--publish`.

Review the scanner instructions before running either tool. A scan run is separate from viewing the findings page; downloading a scanner does not start a scan or publish results.

## Fix a finding with an agent

On **iKASecure → All teams**, open a finding's menu and select **Fix with an agent**. Claude, Copilot and Gemini run on **my machine**; Claude and Copilot also run on **GitHub**. For a dependency finding, **Gemini · GitHub** is greyed out: Gemini on GitHub refuses every edit to `package.json`, lockfiles and `Cargo.toml`, so it can't upgrade a package. Use Gemini on my machine, or Claude or Copilot, instead.

While the agent works, the finding reads **Agent fixing**. When its pull request is open, it reads **In review** until a person merges it. When the fix task is done, the finding becomes **Fixed** by itself. **Mark fixed** and **Reopen** in the menu change a code or dependency finding by hand; a finding marked as a false positive or an accepted risk keeps that status. **Accept the risk** works on an open finding of every kind and needs a reason: open the finding (or **Accept risk…** in its menu), select **Accept the risk**, and write why. The finding then reads **Risk accepted** with your reason, leaves the open counts, and a rescan never opens it again. **Reopen** in the finding undoes it. On an AI finding, **Mark false positive** also needs a reason.

## Security-only API keys

A scanner or CI job needs a key, but not a key to the whole workspace. In **Settings → API Keys**, create the key with **Area** set to **Security only**. That key can read and file security findings, scans and fix tasks through the API and MCP, and nothing else. Add **Read-only key** to stop it from changing anything.

Through MCP, a Security-only key can use these tools:

| Tool | What it does |
| --- | --- |
| `security_summary` | Counts a team's open findings by severity and source, and names the five to fix first. |
| `security_list_findings` | Lists a team's findings from code, AI endpoints and packages, worst first. |
| `security_list_scans` | Lists the code-scan reports and AI endpoint scans filed for a team. |
| `security_list_applications` | Lists the team's applications, the names dependency findings are filed under. |
| `security_set_finding_status` | Marks a finding fixed, a false positive or risk accepted (any source, with a reason), or reopens it. |
| `security_create_fix_task` | Files the fix task for a finding or a missing control in one of the team's projects. |

MCP is the public API. The one REST exception is the four upload routes that the shipped scanners and CI call with a `vk_` key:

- `POST /api/security/scan-reports`
- `POST /api/teams/{id}/security/scan-findings`
- `POST /api/vulnerabilities/bulk`
- `POST /api/teams/{id}/security/ai-seed` (the AI scanner's findings and run)

## Audit log

The audit log is workspace-wide, even though it appears within a team's iKASecure page. It is sorted newest first, supports filtering and search, and retains events for 90 days. Use **CSV** to export the currently filtered rows. Each finding status a person sets, from a screen or `security_set_finding_status`, adds a row: `security.finding_fixed`, `security.finding_reopened`, `security.finding_false_positive` or `security.finding_accepted`, with the source, the finding and the reason. This view is available only to workspace Owners and Admins with the required entitlement.

## Related guidance

See [Data Security](/docs/security/data-security) for how configured AI provider keys and notification text are handled. See [Members & Roles](/docs/teams-projects/members-roles) for team membership and role guidance.