Key facts
| Access control | Scoped API keys with rotation; enterprise SSO and RBAC options |
| Deployment | Cloud, VPC, on-prem or air-gapped for isolated environments |
| Auditability | Request, model, source and tool-call logging |
| Data grounding | Embeddings and RAG are live for runbooks, advisories and procedures |
| Structured output | JSON mode returns triage records and findings in validated schemas |
| Models | 30+ models behind one API, routed by task sensitivity |
| Pricing model | Flat monthly self-serve plans; no per-token billing on self-serve |
| Endpoint roadmap | Moderation, images, audio, batch and fine-tuning are coming soon |
TL;DR
- Treat retrieved documents and web content as untrusted input to the model.
- Keep secrets out of prompts and scope keys to the minimum privilege.
- Sanitize and review any content that enters a retrieval index.
- Log model and tool interactions so investigations have a record.
- Require human verification of AI-generated findings before action.
How it works, step by step
- Inventory AI usage across security operations, engineering and knowledge tools.
- Identify prompt-injection paths where untrusted content reaches the model, and constrain tools accordingly.
- Separate keys by system and privilege; store secrets in a manager, never in prompts or code.
- Sanitize retrieval sources and monitor index updates for poisoned or injected content.
- Require structured, validated output for triage and findings, and review before escalation.
- Log request IDs, model versions, sources, tool calls and outcomes under a retention policy.
- Test red-team scenarios: injection via documents, tool abuse and data-exfiltration attempts.
Try it yourself
Open the AI API key security checklist →
AI as an attack surface
Any workflow that combines untrusted text with tool access is an injection target. Defenses are architectural rather than prompt-level: constrain tools to narrow, permissioned operations, validate every tool call server-side, never expose secrets to the model, and treat retrieved content as untrusted data. Detecting instructions embedded in documents and failing closed beats clever prompts.
Keep retrieval indexes curated and monitored. A poisoned document that enters an index can influence answers long after the original incident.
Secret hygiene and key management
Security teams hold credentials that would be catastrophic in a model context. Enforce a rule: no keys, tokens or customer secrets in prompts, logs or training data. Issue scoped keys per system and environment, store them centrally, rotate on schedule, and audit usage per key for anomalies. See API keys, RBAC and audit logs for the control pattern.
Using AI in security operations
AI helps most with summarization and triage: condensing alerts, drafting incident notes, and retrieving relevant runbooks with citations. It helps least when asked to make a final determination without evidence. Use JSON mode so triage output lands in schemas your tooling validates, and keep a human analyst accountable for every escalation and containment decision.
Route by sensitivity: public advisories can use fast shared models, while internal incident data belongs on a private deployment.
Logging, detection and review
Log request IDs, model and version, retrieved sources, tool calls with arguments and outcomes so investigations can reconstruct events. Monitor for abnormal patterns - unusual tool use, large retrieval volumes or repeated refusals - as detection signals. Review a sample of AI-assisted decisions monthly and feed errors back into prompts, indexes and evaluations.
Honest comparison
| Control area | Plugsky capability | Common gap | Owner |
|---|---|---|---|
| Injection defense | Narrow tools, server-side validation, curated indexes | Unfiltered web content in context | Security architecture |
| Secret hygiene | Scoped keys with rotation and per-key audit | Secrets copied into prompts | AppSec |
| Isolation | VPC, on-prem and air-gapped deployment options | Sensitive incidents on shared tools | Security engineering |
| Audit trail | Request, source and tool-call logging | No reconstruction path | SOC and IR |
| Output verification | JSON mode plus human review of findings | AI findings escalated unreviewed | SOC lead |
| Governance | Approved model list behind one API | Ad-hoc model switching | Security leadership |
Frequently asked questions
What is the biggest AI risk for security teams?
Combining untrusted content with tool access. A document or web page can carry instructions that the model follows. Constrain tools and validate every call server-side rather than relying on prompt wording.
Can we paste logs into the model?
Redact credentials, tokens and personal data first, and prefer retrieval over approved sources. For sensitive incident data, use a private deployment and keep raw logs behind permissioned tools.
How do we secure retrieval content?
Curate indexes, restrict who can publish to them, monitor updates and treat retrieved text as untrusted input. Poisoned documents are a long-lived risk.
Should the moderation endpoint be used for safety?
Moderation is coming soon. Until then, apply your own input and output filters, and keep human review for anything that affects users or systems.
How do we detect misuse of our API keys?
Review usage analytics per key, alert on abnormal volume or tool-call patterns, rotate on schedule and revoke immediately on any suspicion.
What should we log?
Request IDs, model and version, retrieved sources, tool calls with arguments and outcomes. That is the minimum for incident reconstruction and compliance review.
Where do we start?
Map existing AI usage, close injection paths on the highest-risk workflow, then pilot on internal runbooks with the free plan before expanding.