🧱 Security is architecture, not a detail
There’s an order-of-operations mistake that sinks AI projects: treating security as a technical detail that “we’ll deal with later.” When AI only chatted, the worst that could happen was a bad response. But from the moment it executes real tasks — sends an email, changes a record, issues a document, accesses the database—a wrong decision becomes a wrong action in the real world. That’s why security is a architecture decision: it defines, at the design stage, the limits within which the system can act.
🛡️ The wall starts in the project
A security wall isn’t something you throw up in a hurry after a break-in. It’s a foundation: you decide where it goes before you build the house. In Jarvis, that means answering these questions during the design stage: what the system can access, what it must never access, who approves what, and what needs a human before it happens.
⚠️ Warning: the cost of putting it off
Security added at the end is expensive and full of holes. An agent that already has full access to the database, which you try to "limit later," tends to retain forgotten pathways. The damage from a single poorly authorized automated action—a wrong email to a thousand customers, a deleted record—can cost more than all the productivity gains from the project.
🔑 Access Control and Permissions
Access control answers two questions: who can use Jarvis e what each person can ask it to do. The golden rule is the least privilege: each person and each agent gets only the access they actually need to do their job—nothing more. An agent that only answers questions doesn’t need permission to delete records. A support representative doesn’t need the same authority as a manager.
🔐 Three access layers
- Who comes in: only identified people and channels can communicate with the system (login, token, authorized number).
- What it can request: each profile has a set of permitted actions — support agent, salesperson, manager.
- What the agent can interact with: each agent gets permission only for the data and tools used by its service.
✓ Safe permissions
- ✓Each agent accesses only its own service
- ✓Clear roles: attendant ≠ manager
- ✓Least privilege by default
- ✓Access reviewed when the role changes
✗ Unsafe permissions
- ✗One “admin” login for everything and everyone
- ✗Every agent with full access to the database
- ✗"Release everything, we'll lock it down later"
- ✗Access still active for someone who has left the company
🚧 Action limits
Having permission to take an action doesn’t mean you can take it at any scale. Action limits are the boundaries within which each action is allowed: the maximum discount that can be given without approval, how many emails can be sent per hour, the limit for an automatic refund. It’s the difference between “Jarvis can issue an invoice” and “Jarvis can issue an invoice for up to R$ 500; above that, it asks for confirmation.”
💡 Practical tip
For each action Jarvis performs, write a sentence: "it can do X up to limit Y; above that, it asks for Z." If you can’t complete the sentence, the limit isn’t defined yet—and an action without limits is an open door to serious damage.
🔒 Sensitive Data Protection
Jarvis will handle information that can’t be leaked: customer data, contracts, amounts, internal documents. Protecting sensitive data means deciding what the system can see, what it can store, and what must never leave. Privacy here isn’t bureaucracy—it’s what keeps the customer’s trust and the company on the right side of the law (such as the LGPD). The simple rule: Jarvis only accesses the data it needs, for as long as it needs it, and never exposes confidential information.
Handling rule (illustrative)
Illustrative data policy outline — adapted for each service.
✓ Protected data
- ✓Accesses only what the task requires
- ✓Confidential data masked in the response
- ✓No sensitive data leaves the system
- ✓Keep it for the minimum required time, then discard it
✗ Exposed data
- ✗System with access to the entire database
- ✗CPF and card details appearing in the chat
- ✗Customer data pasted into an external service
- ✗Confidential conversation stored forever
👤 Human validation and logs
Two mechanisms close the wall. The first is the human validation: for high-impact actions—irreversible, costly, or sensitive—Jarvis prepares everything, but a human gives the final “OK” before it runs. The second is the log: a record of who asked for what, when, and what the system did. Without a log, you don’t know what happened; with a log, every error can be traced, and monitoring can alert you when something goes wrong.
Jarvis prepares the action
Drafts the email, calculates the refund, writes the document—but still doesn't send it.
A human validates
If the action has a high impact, it stops at an approval point: the person confirms or declines.
Executes and logs
Once approved, the action happens—and everything is recorded in the log: who, what, when.
Monitoring observes
The log feeds monitoring, which alerts you when something deviates from the norm (unusual volume, repeated errors).
💡 Practical tip
Use a simple rule: for a reversible, low-cost action, Jarvis acts on its own and records it; an irreversible, costly, or sensitive action always goes through a human. When in doubt, ask for validation — confirming is cheaper than undoing.
🧪 Separate testing from production
Every change to Jarvis needs a place to fail without causing harm. That’s why two environments are separated: the test, where you experiment, make mistakes, and adjust using fake data; and the production, where the system serves real customers. You never test a new idea directly in production — first prove it in testing, then promote it to production with confidence. Mixing the two is like rehearsing the play in the middle of opening night.
✓ Test environment
- ✓Fake data, fictional customers
- ✓It can make mistakes without causing harm
- ✓A place to experiment with new things
- ✓Real actions (email, billing) disabled
✓ Production environment
- ✓Real data, real customers
- ✓Only receives what has already passed the test
- ✓The change arrives reviewed and stable
- ✓Real actions enabled, with their limits
⚠️ Warning: testing in production
Trying a new automation directly in the live environment is the kind of mistake that becomes a horror story: the test message goes to real customers, the “sample charge” is actually processed, the fake record deletes good data. If there’s no test environment, create one before enabling any action that affects the real world.
Self-check (optional): what is this module's central idea about security?
🛡️ Module summary
Next module:
2.7 — Tools and Integrations: how Jarvis acts in the world, connected to real systems (within the boundaries you just put in place).