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

Select iKASecure in the top bar. It opens the last team you used, or your first team.
Select the required team under Your teams in the left sidebar. To see every team at once, select All teams above that list.
Start on OWASP Top 10 to review code-security findings.
Open Non-OWASP Controls to review hardening controls when your plan includes the security entitlement.
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.
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

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.

Pick What to scan: Everything, Code, AI endpoints, Dependencies or Imported report. Code and Dependencies are the same scan run.
Pick the Team the findings go to.
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.
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.

See Data Security for how configured AI provider keys and notification text are handled. See Members & Roles for team membership and role guidance.