GaaS Security and Privacy: How to Protect Agentic Services
Agentic as a Service creates a different security problem from a normal AI chat or text-generation tool.
A GaaS agent may:
- read files and databases;
- search internal knowledge;
- call APIs;
- create or update records;
- send information to external systems;
- retain task state;
- run on a schedule; and
- continue through several steps without constant human supervision.
Security must therefore protect more than the model.
It must protect the complete path between the user, agent, tools, data, accounts, and external actions.
A practical security model should follow three principles:
- verify every identity and request;
- grant only the access required for the current task; and
- assume that one layer may fail or become compromised.
Why GaaS security is different
Traditional application security usually works with predictable software paths.
Agentic services can make bounded decisions during execution.
An agent may choose:
- which tool to call;
- which source to inspect;
- what information to retrieve;
- whether another step is required;
- when to retry;
- when to ask for approval; and
- when the task is complete.
That flexibility expands the attack surface.
A malicious instruction hidden in a document can influence tool selection.
An overprivileged account can turn a reasoning error into an external change.
A delayed tool response can cause the agent to repeat an action.
Security controls must remain effective even when the agent makes an unexpected decision.
Map the complete security boundary
Begin with a diagram of the service.
Include:
- users;
- service interfaces;
- agent runtime;
- workflows;
- models;
- model providers;
- tools;
- MCP servers;
- accounts;
- credentials;
- local files;
- databases;
- memory stores;
- logs;
- monitoring systems;
- external applications;
- schedules; and
- support access.
For every connection, record:
- identity;
- authentication;
- authorised actions;
- data transferred;
- destination;
- encryption;
- retention;
- owner; and
- revocation method.
Hidden dependencies create hidden risk.
Give every agent a clear identity
Important agents should not act through anonymous or shared identities.
An agent identity should make it possible to determine:
- which agent acted;
- which version was running;
- which workflow authorised it;
- which user or event started the task;
- which account it used;
- which tools it called;
- which reviewer approved the action; and
- when the access ended.
Separate agent identities help with:
- access control;
- activity review;
- incident investigation;
- billing;
- revocation;
- ownership changes; and
- service retirement.
Avoid using one permanent administrator account for several unrelated agents.
Authenticate agents as non-human actors
Agent authentication should be treated as seriously as employee authentication.
Controls may include:
- service identities;
- workload identities;
- short-lived tokens;
- signed requests;
- mutual authentication;
- certificate-based access;
- approved service accounts; and
- device or environment verification.
Static shared keys are difficult to attribute and rotate.
Where possible, use credentials that are:
- limited to one service;
- limited in time;
- limited in scope;
- automatically renewable;
- easy to revoke; and
- recorded in access logs.
Apply least-privilege access
Give the agent only the access needed for its approved task.
Limit permissions by:
- tool;
- account;
- project;
- workspace;
- record type;
- source;
- destination;
- file path;
- URL;
- host;
- port;
- read or write action;
- execution time; and
- task instance.
A research agent should not inherit a user's ability to edit every record.
A report agent should not have delete access.
A test workflow should not reach production.
Least privilege reduces the effect of mistakes, prompt injection, stolen credentials, and compromised tools.
Separate read and write authority
Read and write tools should be separate when possible.
This allows an organisation to:
- run research with read-only access;
- require stronger authentication for writes;
- add approval before external actions;
- rotate write credentials independently;
- monitor sensitive actions separately; and
- disable writes without stopping all service activity.
Write access should be introduced only after read-only testing is reliable.
Delete access should require its own justification and control path.
Use temporary and task-bound permissions
Standing access gives an agent authority even when no task is active.
A stronger model grants access:
- after a valid task begins;
- only to the required resource;
- for a limited period;
- after any required approval; and
- until the task is complete or stopped.
Task-bound access can reduce lateral movement and forgotten permissions.
It also makes agent authority easier to explain.
Protect credentials outside model context
Models should not receive raw secrets.
Store:
- API keys;
- access tokens;
- passwords;
- database credentials;
- private headers; and
- client secrets
in approved secure credential storage.
Tools should receive the secret through the execution environment rather than through the prompt.
Credentials should never appear in:
- user instructions;
- workflow text;
- retrieved documents;
- long-term memory;
- generated output;
- screenshots;
- ordinary logs; or
- support messages.
Establish a credential lifecycle
Every credential needs:
- an owner;
- a purpose;
- a scope;
- a creation date;
- an expiry process;
- a rotation process;
- a revocation method;
- a recovery method; and
- a list of dependent services.
Rotate or revoke credentials after:
- suspected exposure;
- staff changes;
- device loss;
- provider changes;
- server migration;
- permission changes;
- incidents; or
- service retirement.
Removing a visible integration does not always revoke the external credential.
Treat retrieved content as untrusted
Agents may read websites, documents, messages, database fields, and tool output.
Any of these can contain direct or indirect prompt injection.
A malicious source may instruct the agent to:
- ignore its real task;
- reveal private information;
- call another tool;
- change a destination;
- send data externally;
- execute code; or
- hide its actions.
Retrieved text must be treated as content to analyse, not authority to obey.
Use layered prompt-injection controls
No single prompt can fully prevent prompt injection.
Use several controls together:
- isolate system instructions from retrieved content;
- label external content clearly;
- limit available tools;
- sanitise URLs, metadata, and hidden content;
- validate tool parameters;
- restrict destinations;
- block unsupported actions;
- require approval for sensitive writes;
- detect unusual instruction patterns;
- test adversarial examples; and
- monitor unexpected behaviour.
The strongest protection is limiting what a compromised agent can do.
Validate every tool call
Tool requests should pass through controls outside the model.
Validate:
- tool name;
- input schema;
- required fields;
- allowed values;
- source;
- destination;
- account;
- file path;
- URL;
- record identifier;
- write permission;
- approval status; and
- task budget.
Reject unexpected or malformed requests.
The model's decision to call a tool should not automatically authorise the action.
Secure MCP and external tool servers
MCP servers and other tool services can expose powerful capabilities.
Review:
- server owner;
- endpoint;
- authentication;
- transport security;
- discovered tools;
- tool descriptions;
- read and write behaviour;
- source access;
- destination access;
- version;
- update process;
- logs;
- network exposure; and
- shutdown procedure.
Treat a new or changed tool as unapproved until it has been reviewed and tested.
Do not expose a local MCP server broadly when it only needs local access.
Isolate agent execution
Agents that execute code, open files, or interact with systems should run in appropriately isolated environments.
Isolation may include:
- containers;
- sandboxes;
- separate operating-system users;
- restricted file systems;
- limited network routes;
- temporary workspaces;
- read-only mounts;
- resource limits; and
- execution timeouts.
Isolation helps prevent one compromised task from affecting the wider host or another customer.
Separate customers, teams, and environments
GaaS providers should prevent data or actions from crossing boundaries.
Separate:
- customer data;
- customer memory;
- logs;
- credentials;
- vector stores;
- tool connections;
- test environments;
- production environments; and
- support access.
Verify isolation through testing rather than relying only on architectural claims.
Control network access
Agents should not receive unrestricted network access by default.
Limit:
- domains;
- URLs;
- IP addresses;
- ports;
- protocols;
- redirects;
- private networks;
- internet access; and
- outbound destinations.
A tool that needs one API should not be able to contact any internet host.
Validate the final destination after redirects.
Control file-system access
Limit agents to approved folders.
Separate:
- source folders;
- temporary workspaces;
- generated output;
- credential storage;
- application files;
- logs; and
- backups.
Use read-only access where possible.
Prevent path traversal and symbolic-link abuse.
A document agent should not be able to search an entire device because one folder is required.
Protect task state and memory
Agent state may contain sensitive information.
It can include:
- user instructions;
- retrieved records;
- intermediate conclusions;
- tool output;
- approval data;
- errors;
- personal preferences; and
- unresolved work.
Define:
- what is stored;
- why it is stored;
- where it is stored;
- who can access it;
- how long it is retained;
- how it is corrected;
- how it is encrypted; and
- how it is deleted.
Long-term memory should be opt-in or purpose-based, not automatic.
Minimise data collection
Send only the information required for the task.
Avoid giving the agent:
- full customer profiles when one field is needed;
- complete documents when one section is relevant;
- entire message histories by default;
- unrelated personal information;
- broad file collections;
- hidden credentials; or
- indefinite conversation history.
Data minimisation reduces privacy exposure, cost, and model distraction.
Control retention and deletion
Set separate retention periods for:
- task state;
- user input;
- tool output;
- generated output;
- long-term memory;
- activity logs;
- security logs;
- backups; and
- evaluation data.
Users and administrators should know how information is deleted.
Deletion should cover backups and provider subprocessors where required.
Do not retain data indefinitely merely because storage is available.
Review model-provider data handling
A GaaS service may send information to one or more model providers.
Confirm:
- provider identity;
- processing location;
- retention;
- training use;
- logging;
- subcontractors;
- encryption;
- deletion;
- incident notification; and
- model-routing changes.
If the service can switch models dynamically, customers should understand when data may move to another provider.
Secure human approval
Approval steps can become security controls only when they are specific and authenticated.
The reviewer should see:
- exact action;
- exact destination;
- affected item;
- current value;
- proposed value;
- supporting evidence;
- warning;
- reversibility; and
- agent identity.
Record who approved the action and when.
Require new approval if the proposal changes.
Prevent duplicate and replayed actions
Use:
- unique task identifiers;
- unique action identifiers;
- idempotency controls;
- timestamps;
- request signatures;
- destination checks;
- limited retries; and
- replay protection.
Before retrying a write, verify whether the original action completed.
This is especially important for messages, records, files, payments, and access changes.
Record security-relevant activity
Logs should make the action path reconstructable.
Record:
- initiating identity;
- agent identity;
- workflow version;
- model;
- tool;
- account;
- source;
- destination;
- parameters;
- approval;
- result;
- warning;
- error;
- retry;
- timestamp; and
- final status.
Protect logs from unauthorised changes.
Do not place raw credentials or unnecessary sensitive content in them.
Monitor agent behaviour continuously
Detect:
- unusual tool selection;
- unexpected destinations;
- permission failures;
- repeated retries;
- sudden cost growth;
- large data transfers;
- new tools;
- model changes;
- unusual execution times;
- duplicate actions;
- schedule changes; and
- attempts to access blocked resources.
Compare current behaviour with the expected pattern for the service.
Design for containment
Assume that an agent, tool, credential, or provider may become unsafe.
Prepare controls to:
- pause the agent;
- stop schedules;
- disable writes;
- revoke credentials;
- block a destination;
- isolate a server;
- stop a local process;
- preserve evidence;
- notify owners;
- verify external actions; and
- restore from a known-good state.
Containment should not require rebuilding the entire environment.
Test security controls
Test more than normal task completion.
Include:
- direct prompt injection;
- indirect prompt injection;
- malicious document content;
- hidden URL instructions;
- invalid tool parameters;
- blocked paths;
- blocked domains;
- expired credentials;
- stolen-token simulation;
- cross-customer access attempts;
- excessive data requests;
- write timeout;
- replayed requests;
- duplicate actions;
- model outage;
- tool-server compromise; and
- denied approval.
Use safe test data and environments.
Manage privacy requests
The service should support applicable requests to:
- access stored information;
- correct inaccurate memory;
- delete retained data;
- export records;
- explain automated involvement; and
- challenge important decisions.
The exact obligations depend on the use case and location.
Privacy processes should include agent state, memory, logs, and third-party providers where relevant.
Review support and administrator access
Provider or internal support staff may have powerful access.
Control:
- who can access customer environments;
- why access is needed;
- approval;
- duration;
- session recording;
- actions performed;
- credential use;
- emergency access; and
- access removal.
Administrative access should be time-limited and reviewed.
Secure local and hybrid GaaS
Local execution can reduce some remote data movement.
It creates additional responsibilities for:
- device identity;
- operating-system accounts;
- disk encryption;
- local credential storage;
- model files;
- local MCP services;
- firewall rules;
- open ports;
- backups;
- physical access;
- sleep and restart behaviour; and
- device retirement.
A local model does not make remote tools or storage local.
Review the full path.
How Feluda can support secure GaaS
Feluda can support controlled local, cloud, and hybrid agentic workflows.
AI Providers makes model choice explicit.
Studio can combine agentic steps with deterministic rules, branches, approvals, and error paths.
MCP Servers and Genes can expose focused tools rather than one unrestricted capability set.
Permissions can constrain URLs, IP addresses, file paths, and ports.
Workbench Activity and RunFlows can expose tool calls, results, warnings, and errors.
Schedule Manager can pause recurring execution when a dependency or destination becomes unsafe.
Local models and desktop operation can reduce remote processing for selected workflows.
These controls are effective only when users configure, test, and review them for the specific service.
GaaS security checklist
Confirm that:
- every agent has an owner and identity;
- users, agents, and tools are authenticated;
- access is task-specific;
- read and write permissions are separated;
- credentials remain outside model context;
- retrieved content is treated as untrusted;
- tool calls are validated;
- MCP servers are reviewed;
- execution is isolated;
- customer and environment boundaries are tested;
- network and file access are restricted;
- state and memory are protected;
- data collection is minimised;
- retention and deletion are defined;
- model-provider data handling is known;
- approvals bind to exact actions;
- duplicate and replay protection exists;
- activity is recorded securely;
- agent behaviour is monitored;
- containment controls are ready;
- security tests include adversarial cases;
- support access is controlled; and
- local devices are secured and retired properly.
The practical conclusion
GaaS security is the security of delegated action.
The agent does not only process information.
It may use identities, tools, data, networks, files, and external systems on behalf of a person or organisation.
Secure GaaS therefore requires a zero-trust approach:
- verify every actor;
- authorise every action;
- minimise every permission;
- treat external content as untrusted;
- isolate execution;
- preserve evidence;
- monitor continuously; and
- prepare to contain failure.
The most secure agent is not the one with the most sophisticated prompt.
It is the one whose authority remains narrow and whose actions can always be understood, stopped, and reversed where possible.