AI / AI-06
AI agent and enterprise-action security
Govern AI that can use tools or act: least privilege, task boundaries, approval of sensitive operations and a stop mechanism. An agent must not automatically inherit every permission of its operator.
WHEN IT HELPS
A focused response
to a defined need.
Agent connected to CRM, ticketing, email, files or administration; automation requesting elevated access; need to control actions and their cost.
SCOPE & OUTCOMES
What the engagement covers.
Scope
- Tool inventory
- dedicated identity
- permissions
- read/write separation
- allowed destinations
- human approval
- transactions
- quotas
- logs
- stopping
- revocation and abuse testing
Deliverables
- Tool/action matrix
- approval rules
- restricted identities
- stop procedures
- tests
- audit log
- operations instructions
- excluded-action register
Acceptance evidence
Out-of-scope actions are denied; sensitive parameters are visible to approvers; stopping and revocation are tested; logs are usable; call and retry limits are effective.
DELIVERY
How the work is structured.
Approach
Choose a use case; classify data and access; design and pilot; test privacy, actions and cost; decide rollout and monitoring.
Prerequisites & responsibilities
Customer: business sponsor, data owners, identity team, DPO/legal where needed and budget. Provider: architecture and tests; customer retains approval of sensitive use.
Scope factors
Uses, users, models, data, connectors, permissions, actions, volumes and hosting. Separate project, licenses, tokens, search, storage and operations; no claimed savings without measurement.
Questions to clarify
Which actions have external or irreversible effects? Who approves the specific action before execution? What can the agent do when a tool returns misleading instructions?
IMPORTANT BOUNDARIES
A system message alone is not a security boundary. Tools and services must enforce permissions; approval must cover the actual action rather than a vague intention.
Permissions, provider data use, retention, residency and cost enforcement are assessed separately. Technical features and applicable obligations are checked for the chosen offering and use case.
IN PRACTICE
Illustrative situations.
These examples describe possible engagements and target outcomes. They are not customer references or achieved results.
Scenario 01
An agent drafts sales responses and can send them. Project: separate drafting from sending, with recipient and content approval. Target outcome: useful assistance without unapproved autonomous external messages.
Scenario 02
A team wants a technical-remediation agent. Project: initially limit it to analysis and approved reversible changes. Target outcome: traceable actions; data deletion and privilege changes remain prohibited outside a stronger procedure.
Technology and reference context
Examples: application identities, tool gateways, connector controls and approval-based orchestration; OWASP GenAI references.
The final technology set is agreed during scoping, based on interoperability, licensing, access rights and operating requirements.
CONNECTED SERVICES
Build the next step.
These services can complement the engagement. They are not automatically included.
START A CONVERSATION
Make the scope clear.
We will clarify the objective, dependencies and responsibilities of this service before proposing delivery.